如何科学破解慢SQL?

SQL语句的执行过程

存储引擎和索引的那些事儿

慢SQL解决之道

后续均以MySQL默认存储引擎InnoDB为例进行展开，话不多说，开搞！

慢SQL，就是跑得很慢的SQL语句，你可能会问慢SQL会有啥问题吗？

试想一个场景：

大白和小黑端午出去玩，机票太贵于是买了高铁，火车站的人真是乌央乌央的。

马上检票了，大白和小黑准备去厕所清理下库存，坑位不多，排队的人还真不少。

小黑发现其中有3个坑的乘客贼慢，其他2个坑位换了好几波人，这3位坑主就是不出来。

等在外面的大伙，心里很是不爽，长期占用公共资源，后面的人没法用。

小黑苦笑道：这不就是厕所版的慢SQL嘛！

这是实际生活中的例子，换到MySQL服务器也是一样的，毕竟科技源自生活嘛。

MySQL服务器的资源(CPU、IO、内存等)是有限的，尤其在高并发场景下需要快速处理掉请求，否则一旦出现慢SQL就会阻塞掉很多正常的请求，造成大面积的失败/超时等。

客户端和MySQL服务端的交互过程简介：

客户端发送一条SQL语句给服务端，服务端的连接器先进行账号/密码、权限等环节验证，有异常直接拒绝请求。

服务端查询缓存，如果SQL语句命中了缓存，则返回缓存中的结果，否则继续处理。

服务端对SQL语句进行词法解析、语法解析、预处理来检查SQL语句的合法性。

服务端通过优化器对之前生成的解析树进行优化处理，生成最优的物理执行计划。

将生成的物理执行计划调用存储引擎的相关接口，进行数据查询和处理。

处理完成后将结果返回客户端。

客户端和MySQL服务端的交互过程简图：

俗话说"条条大路通罗马"，优化器的作用就是找到这么多路中最优的那一条。

存储引擎更是决定SQL执行的核心组件，适当了解其中原理十分有益。

InnoDB存储引擎(Storage Engine)是MySQL默认之选，所以非常典型。

存储引擎的主要作用是进行数据的存取和检索，也是真正执行SQL语句的组件。

InnoDB的整体架构分为两个部分：内存架构和磁盘架构，如图：

存储引擎的内容非常多，并不是一篇文章能说清楚的，本文不过多展开，我们在此只需要了解内存架构和磁盘架构的大致组成即可。

InnoDB 引擎是面向行存储的，数据都是存储在磁盘的数据页中，数据页里面按照固定的行格式存储着每一行数据。

行格式主要分为四种类型Compact、Redundant、Dynamic和Compressed，默认为Compact格式。

当计算机访问一个数据时，不仅会加载当前数据所在的数据页，还会将当前数据页相邻的数据页一同加载到内存，磁盘预读的长度一般为页的整倍数，从而有效降低磁盘IO的次数。

MySQL中磁盘的数据需要被交换到内存，才能完成一次SQL交互，大致如图：

扇区是硬盘的读写的基本单位，通常情况下每个扇区的大小是 512B

磁盘块文件系统读写数据的最小单位，相邻的扇区组合在一起形成一个块，一般是4KB

页是内存的最小存储单位，页的大小通常为磁盘块大小的 2^n 倍