本文主要是通过对PFS引擎的内存管理的源码的阅读，解读PFS内存分配及释放原理，深入剖析其中存在的一些问题，以及一些改进思路。

在我们的开发过程中，经常会在一个项目中使用多种数据库系统。在一些特定场景下，我们希望把数据从一种数据库，同步到另一种异构的数据库，以便进行数据分析统计、完成实时监控、实时搜索等功能。这个异构数据源同步的过程称为Change Data Capture（变化数据捕获）。

我们本文讨论的是Source为MySQL、Target为ElasticSearch的场景下，进行增量和全量同步操作过程。众所周知，MySQL数据库凭借其性能卓越、服务稳定、开放源代码、社区活跃等因素，成为当下最流行的关系型数据库，但是在数据量级较大或涉及到多表操作时，亦或是需要根据地理位置进行查询时，MySQL通常不能给我们很好的支持。

为了解决MySQL查询缓慢、无法查询的问题，我们通常采用ElasticSearch等进行配合检索。在传统方式中，将MySQL同步数据到ElasticSearch通常采用的是双写、MQ消息等形式，这些形式都存在着耦合高、性能差、丢失数据等风险。

所以我们需要探索出一套对业务无侵入的MySQL同步至ElasticSearch异构数据库的解决方案。本文将分别从增量同步、全量同步两个层面进行探讨。

文章通过MySQL官方文档和MySQL源码两个方面，分析了MySQL主从复制延迟参数Seconds_Behind_Master是如何计算的。

本篇介绍子查询、分区表和JOIN的复杂转换过程。

用量化的思维解决慢查询。

一般来说讲，提到数据拆分，总归可以归结为两个层面：一是垂直拆分，二是水平拆分。这里我们来讨论下垂直拆分。

MySQL 配置文件和 mysqld.service 中都声明了可打开的最大文件数时，哪个在生效？

在日常开发工作中，我们几乎需要天天与数据库打交道，作为一名只会CRUD的SQL BOY，除了每天用mybatis-generator自动生成DAO层代码之外，我们几乎不用去care数据库中如何处理并发请求，但是突然某一天MYSQL数据库告警了，出现了死锁，我们的内心慌的一匹，不禁想问：这不就是个普通查询吗，咋还锁起来了？

为了避免慌乱的表情被主管捕捉到，我们需要提前了解一下数据库中到底有哪些锁。

在MySQL中，其实将锁分成了两类：锁类型（lock_type）和锁模式（lock_mode）。

锁类型描述的锁的粒度，也就是把锁具体加在什么地方；而锁模式描述的是到底加的是什么锁，是读锁还是写锁。锁模式通常和锁类型结合使用。

本文重点介绍了下优化器的基于规则的其中一部分优化，更多的偏重于SQL中的基本操作符。

在生产中一般发生运行问题，可以翻翻 error 日志，大部分都能解决。有的时候数据库突然宕机重启，此时我们在 error 日志中会发现"This could be because you hit a bug"，然后打了一堆看不懂的堆栈。这时候如果拿着碰到BUG的结论交差，多半会被应用一顿暴击输出：有证据没，这个 bug 怎么出现的，官方怎么修的，在什么版本修的。那么接下来，我将根据现有 error 日志报错中的堆栈信息，找到详细的 BUG 修复记录。

基于MySQL BinLog日志的同步系统，将MySQL中的数据实时同步到其他数据库（Redis、ElasticSearch、HBase），简单配置即可完成数据的异构存储。

最近组内同学遇到一个问题，说数据库被业务打死了，无响应，只好用 kill -9 pid 杀掉，然后重启，幸好此时的数据库角色是从库，影响不大。同学自述，在杀掉重启的时候，心里默念，千万别启不来啊，这个库的数据量有点大，快要达到 4T 了。做运维的人都知道，事情就不能念叨，一念叨，这事儿就准发生。这次也不例外，确实是出现了。现象是长时间启动不了，基本卡死状态。

本文又是来源于客户咨询的问题：能否控制单表在一个固定的记录数，比如说1W条，超过不让插入新记录或者说直接抛出错误？

一道 Sequence 的“开水白菜”，敬请“享用”。

订单系统存在于各行各业，如电商订单、银行流水、运营商话费账单等，是一个非常广泛、通用的系统。对于这类系统，在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展，以及各企业对数据的重视，需要存储和持久化的订单量越来越大，数据的重视程度与数据规模的膨胀带来了新的挑战。首先，订单量对于数据的存储、持久化、访问带来了挑战，这不仅增加了开发面对的困难，也为系统的运维带来了挑战。其次，随着大数据技术的发展以及运营水平的不断提高，订单数据的后续数据分析工作，如流批处理、ETL，也越来越重要，这也对数据的存储系统提出了更高的要求。

本文提出了一种基于MySQL + Tablestore 的大规模订单系统设计方案。这种方案基于分层存储的思想，使用 Tablestore 辅助 MySQL 共同完成订单系统支持。在系统中，利用 MySQL 的事务能力来处理对事务强需求的写操作与部分读操作；利用 Tablestore 的检索能力、大数据存储能力等弥补 MySQL 在功能上的短板。

我们在做数据库性能压力测试、做监控和告警项，或者想要真实地了解业务数据库负载的时候，常常需要使用两个数字化的衡量指标。他们是什么？相信很多数据库从业的读者已经呼之欲出了，那就是 QPS 和 TPS。

我们经常使用到这两个指标，那我们是否清楚他们是什么，在 MySQL 中应该如何计算获得呢？