MySQL 内核深度优化，java面试八股文汇总

1.主备DB间的复制优化

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1daZyWpk-1637470516839)(https://segmentfault.com/img/bVbcCFY?w=798&h=330 “clipboard.png”)]

问题分析

如上图所示，在原生MySQL的复制架构中，Master侧通过Dump线程不断发送Binlog事件给Slave的I/O线程，Slave的I/O线程在接受到Binlog事件后，有两个主要的动作：

• 写入到Relay Log中，这个过程会和Slave SQL线程争抢保护Relay Log的锁。

• 更新复制元数据(包含Master的位置等信息)。

优化方法

经过分析，我们的优化策略是：

• Slave I/O线程和Slave SQL线程是典型的单写单读生产者-消费者模型，是可以做到无锁设计的；因此实现思路就是SlaveI/O线程在每次写完数据后，原子更新Relay Log的长度信息，Slave SQL线程读取RelayLog的时以长度信息为边界。这样就将原本竞争激烈的Relay Log锁化解为无锁；

• 由于Binlog事件中的GTID(Global Transaction Identifier)和DB事务是一一对应的关系，所以RelayLog中的数据本身已经包含了所需要的复制元数据，所以我们可以不写Master info文件，消除了冗余的文件I/O；

• 于DB都是以事务为更新粒度的，因为在RelayLog文件I/O上，我们通过合并离散小I/O为事务粒度的大I/O等手段，使磁盘I/O得以大幅提升。

优化效果

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sZboKikf-1637470516857)(https://segmentfault.com/img/bVbcCF6?w=794&h=399 “clipboard.png”)]

如上图所示，经过优化：左图35.79%的锁竞争(futex)已经被完全消除；同压测压力下，56.15%的文件I/O开销被优化到19.16%，Slave I/O线程被优化为预期的I/O密集型线程。

2.主库事务线程和Dump线程间的优化

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1hrW7u3S-1637470516858)(https://segmentfault.com/img/bVbcCF8?w=757&h=284 “clipboard.png”)]

问题分析

如上图所示，在原生MySQL中多个事务提交线程TrxN和多个Dump线程之间会同时竞争Binlog文件资源的保护锁，多个事务提交线程对Binlog执行写入，多个Dump线程从Binlog文件读取数据并发送给Slave。所有的线程之间是串行执行的！

优化方法

经过分析，我们的优化策略是：

• 将读写分离开来，多个写入的线程还是在锁保护下串行执行，每一个写入线程写入完成后更新当前Binlog的长度信息，多个Dump线程以Binlog文件的长度信息为读取边界，多个Dump线程之间并行执行。以这种方式来让复制拓扑中的Dump线程发送得更快！

效果

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fcD9dPY7-1637470516860)(https://segmentfault.com/img/bVbcCGl?w=715&h=265 “clipboard.png”)]

经过测试，优化后的内核，不仅提升了事务提交线程的性能，在Dump线程较多的情况下，对主从复制性能有较大提升。

二.主备库交互流程优化

---

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cprohRm7-1637470516861)(https://segmentfault.com/img/bVbcCGo?w=812&h=310 “clipboard.png”)]

问题分析

如上图所示，在原生MySQL中主备库之间的数据发送和ACK回应是简单的串行执行，在上一个事件ACK回应到达之前，不允许继续发送下一个事件；这个行为在跨园区(RTT 2-3ms)的情况性能非常差，而且也不能很好地利用带宽优势。

优化方法

经过分析，我们的优化策略是：

• 将发送和ACK回应的接收独立到不同的线程中，由于发送和接收都是基于TCP流的传输，所以时序性是有保障的；这样发送线程可以在未收ACK之前继续

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

发送，接受线程收到ACK后唤醒等待的线程执行相应的任务。

效果

根据实际用例测试，优化后的TPS提升为15%左右。

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

发送，接受线程收到ACK后唤醒等待的线程执行相应的任务。

效果

根据实际用例测试，优化后的TPS提升为15%左右。