上周二，晚上十一点的时候，线上忽然出现报警情况。有一个报表接口，原本是50ms，却飙升到了12秒。
当时，我正处于撸串的状态，然后放下了烤鸡翅，紧接着就把电脑给打开了。那种胃痉挛感，是熟悉的，又再次出现了。
进行慢查询日志的查询，所锁定的是一条带有group by操作的用于统计的SQL语句。当进行查看时，Extra列显著呈现出“Using ; Using ”。
该死。
临时表，文件排序，这两个方面同时呈现，大致而言就是在宣称你的数据库将会被拖垮哟。
凭什么？
当我目光直直地注视着屏幕，处于发呆状态之时，我的脑海之中忽然间涌现出了一个问题，即那MySQL到究竟是以怎样的方式去执行这条SQL语句的呢，它为何偏偏一定要创建一个临时表呢？
这不是装逼。是实在被搞烦了。
我耗费了三天的时长，将MySQL 8.0.25的源码给拉取下来，逐行逐行地去查看它。老实讲，那C++代码看上去仿若天书一般，但咬着牙死磕并且最终做到了，很多相关的内容实际上并非那么玄奥莫测费解。
MySQL的请求流程
SQL在从客户端发送过来的那个时刻，最先遭遇的是连接器，这一物件仿若一处门卫之所，要对用户名密码就行核验之举，还要获取相关权限，之后便静候着你的指令。
跟着就抵达了解析器，是其利用Bison去生成语法树，将SQL拆解成以及这类事物，你此刻难道不就已经清楚 from union究竟是怎么一回事了么。
接下来是优化器。这块最折磨人。
将我那个带有group by的检索查询，优化工具所生成的执行策划里面，竟然运用了两种不一样的轨迹路径。后期翻阅代码之后才明白，MySQL在评定是否需要临时表格的时候，会核查group by的列是否构成有秩序的索引。
若是列呈现出有序的状态，那么它会踏上sort 这条路线，径直于排序完结了的数据流范围内进行聚合，要是处于无序状态，那就规规矩矩地去构建临时表。
我的那张表格之中，进行分组依据的列不存在索引，于是呢，它选择了临时表格，并非是它愚笨，而是我未曾告知它更为优良的路径。
加上复合索引之后，临时表不见了，查询用时从十二秒降低到零点三秒。提升了四十倍之多啊，这就如同那一层窗户纸一般。
Pool为何重要
在翻阅源码之际，瞅见了名为af的这个函数。其所做之事是颇为简单的哦：首先去尝试一下自适应哈希索引是否能够命中，要是不行，那就进行B+树搜索。
这便是为何 pool如此关键，ize你将其设置得过小，热点数据无法存储，每次进行查询都不得不前往磁盘读取，如此一来不慢才怪呢。
可是设置成多大才恰当呢？我曾经所经历过的那些挫折会告诉你，不要超出物理内存的百分之七十，要留出一部分给操作系统以及其他进程。
Redo Log的奥秘
还看了语句的流程。
处理时，先是将数据页读取到 pool之中，接着加上X锁，随后把修改前的值写入undo log，再把修改记录写入redo log的log 里。
接着进行，在这个时候光盘要不要被刷新，是由这个参数来决定的。
设成1：每次都刷，最安全，但慢。
设成2：写操作系统缓存，不刷盘，折中。
设成0：每秒才刷一次，最快，但宕机丢一秒数据。
之前我一直采用默认的那个1，往后察觉到业务对于丢失数据的现象是能够包容的，于是就将其改成了2，结果写入性能实现了三倍的提升。
经验：别死记硬背参数，翻翻源码你就知道它到底在干什么。
翻源码这件事，听上去像是顶级DBA才做的事。
但实际上并不需要将所有代码都看懂，你只要看懂一个关键函数的逻辑，像af ，就能够明白索引对于从始至终依据此不走选择另行选择所涉及的原因，你只要懂:: ，就明白了行锁在何种情形下会升级成为表锁。
文章里没有这些知识，网上的调优指南清一色都是“加索引”“改参数”，然而呢，从不跟你讲为啥要这么去做呀。
当被问及那种就连官方文档都未能弄明白搞定的问题之际，源码便成了你手中最后的一张底牌。并且去说明表述我已然翻阅查看过源码进行了确认，如此一来，领导都会觉着你具备专业性。
那个凌晨三点，我关了电脑，窗外传来有鸟叫。
对于四点的城市，已经很久没有看过了。并非是因为加班，而是那种主动去学习东西时所拥有的心安状态。
需明确的是，不要害怕。对于C++不理解？无妨之事，首先要弄明白函数名称以及注释。源码的结构过于杂乱？并无大碍，先从其中一个函数开始着手，就像那个。
这一次慢查询没白熬。
希望下次你不会像我一样，在凌晨三点看着发呆。
早点学会看源码，早点下班。
