Lixora's DB Home

我们知道InnoDB的索引组织结构为Btree。通常情况下，我们需要根据查询条件，从根节点开始寻路到叶子节点，找到满足条件的记录。为了减少寻路开销，InnoDB本身做了几点优化。首先，对于连续记录扫描，InnoDB在满足比较严格的条件时采用row cache的方式连续读取8条记录（并将记录格式转换成MySQL Format），存储在线程私有的中；这样一次寻路就可以获取多条记录，在server层处理完一条记录后，可以直接从cache中取数据而无需再次寻路，直到cache中数据取完，再进行下一轮。

如果当前用户频繁使用相似的query进行查询，Plan Cache可以有效的减少query的优化时间，进而提升query的执行性能。目前Plan Cache是我们开发的第一个版本，只是针对我们线上的场景进行优化，很多场景还不支持。希望在未来的时间里可以完善Plan Cache，提供更多的场景支持。

AST是一种树状结构，它反映了查询语句的语法层次，是一个抽象表示，用于更方便地进行语法和语义分析。查询的执行过程中，MySQL会首先进行语法解析，将查询语句转换成AST。然后，优化器利用这个AST来考虑不同的执行计划，以找到最有效的执行方式。在这个优化过程中，MySQL会考虑许多因素，包括表的访问顺序、使用索引的方式等，以确保查询在性能上得到最优化。简而言之，AST是一个树状结构，用于表示查询语句的抽象语法，而MySQL的优化器使用这个AST来进行查询优化，选择最佳的执行计划。

我们知道InnoDB的索引组织结构为Btree。通常情况下，我们需要根据查询条件，从根节点开始寻路到叶子节点，找到满足条件的记录。为了减少寻路开销，InnoDB本身做了几点优化。首先，对于连续记录扫描，InnoDB在满足比较严格的条件时采用row cache的方式连续读取8条记录（并将记录格式转换成MySQL Format），存储在线程私有的中；这样一次寻路就可以获取多条记录，在server层处理完一条记录后，可以直接从cache中取数据而无需再次寻路，直到cache中数据取完，再进行下一轮。

InnoDB的多版本并不是直接存储多个版本的数据，而是所有更改操作利用行锁做并发控制，这样对某一行的更新操作是串行化的，然后用Undo log记录串行化的结果。当快照读的时候，利用Undo log重建需要读取版本的数据，从而实现读写并发。

利用上面的工具可以很详细的分析出cpu的消耗分布和内存的一个具体占用情况。mysql的性能诊断除了上面我提的几点，当然还有很多其他的办法我就不一一列出了（比如网络等等），更微粒度的监控数据采集，更多维度多功能的问题诊断分析，数据库性能问题的诊断将不是问题。以后的数据库将迈着自治的道路上去走，有感兴趣的同学可以与我交流，共同进步。

InnoDB中undo日志设计及实现相对清晰，但涉及的地方比较多，有些地方设计的比较巧妙，需要仔细的研究，整体对undo日志这块做下梳理。

InnoDB中的数据访问是以Page为单位的，每个Page的大小默认为16KB，Buffer Pool是用来管理和缓存这些Page的。InnoDB将一块连续的内存大小划分给Buffer Pool来使用，并将其划分为多个Buffer Pool Instance来更好地管理这块内存，每个Instance的大小都是相等的，通过算法保证一个Page只会在一个特定的Instance中，划分为多个Instance的模式提升了Buffer Pool的并发性能。

本文重点介绍了Optimizer trace的详细内容，只有深入了解这个工具本身的内容，才能真正具体分析优化器究竟做了哪些事情，根据哪些已有的索引、代价和优化方法进行了选择，基于什么原因做的选择。虽然JSON结果看起来复杂，但是仍然可以辅助DBA去发现性能问题，验证一些优化方法，希望这篇文章对大家有所帮助。

本文聚焦于InnoDB中的Buffer Pool的核心功能，首先从宏观上介绍其背景，包括设计目标、接口、遇到的问题及替换算法的选择等；然后后从使用者的角度介绍了Buffer Pool作为一个整体对外暴露的统一接口和调用方式；之后介绍了Buffer Pool内部获取Page的详细过程以及LRU替换算法的实现；再之后介绍了Page刷脏的触发因素及过程；最后梳理了Buffer Pool如何安全的实现高并发高性能。

刷盘写入数据文件由DBLWR部分完成，为异步IO，异步IO主要为前台thread 发起io_submit，后台异步IO线程堵塞等待结果，然后处理完成的一些动作，比如检查page的IO状态，数据文件的fsync操作，刷盘后一个更加重要的动作是异步IO线程还要完成内存的维护，比如对于flush list刷脏需要从flush list链表中删除，对于lru刷脏则额外还需要从page的hash结构和LRU链表中删除并且返回给free list成为可用的空闲page。下面是一些主要流程供参考，

前面介绍数据字典是 MySQL 维护元数据的模块，MySQL 真正操作表数据是基于表定义对象 TABLE，和存储引擎和数据打交道，每个 TABLE 内有一个handler，表示使用的引擎对象，Innodb 引擎对应的表定义信息是 dict_table_t，TABLE 对表保留有操作数据的必备的信息，如表及字段的特征信息，元数据锁，record 查找结果等。每次执行 SQL 时，都会将涉及的表列表（TABLE_LIST，如 Join 多个表）逐个 open，

的，一个区默认占用 1MB 的空间，如果为段中很小的数据量申请区，则会造成大量空间的浪费，所以 InnoDB 提出了碎片区的概念，碎片区中的页并不都是为了存储同一个段中的数据而存在的，比如有的页用于段 A，有的用于段 B，有的页甚至哪个段也不属于。存放叶子节点的区的集合就算是一个段，存放非叶子节点的区的集合也算是一个段。上一个或多个实际的文件，默认情况下，InnoDB 会在数据目录下创建一个名为 ibdata1 的文件，大小为 12MB，这个文件就是对应的系统表空间在文件系统上的表示。