企业官网建设流程全解析

1. 一条 SELECT 从客户端发起，MySQL 内部要过哪些关卡

1.1 整条链路先看一眼全貌

很多刚开始接触 MySQL 的同学，对“执行一条 SQL”的理解就是：把语句丢给数据库，数据库查找数据，返回结果。这么说没错，但真实情况远不止这么简单。一条SELECT * FROM user WHERE id = 123从发出到拿到结果，中间至少经过连接器、解析器、优化器、执行器、存储引擎这几层，每一层都有自己明确的职责和边界。

这里先给一个全局视角，后面每一层我们再拆开讲：

• 客户端/驱动层：负责建立网络连接、发送 SQL 文本、接收结果集。
• 连接管理与鉴权：校验用户名密码，确认你有权限登录，并把连接纳入 MySQL 的会话管理体系。
• 解析与预处理：把 SQL 文本拆成 MySQL 能理解的数据结构，检查语法、表名、列名、权限。
• 优化器：从多种可能的执行路径中挑一个代价最小的，生成执行计划。
• 执行器：根据执行计划，一步步调用存储引擎接口，处理返回的行数据。
• 存储引擎层：真正和磁盘、缓冲池打交道，负责数据的读取和返回。

这其实很像一次外卖下单的流程：你（客户端）打电话（连接器）下单，接单员记录需求（解析器）并确认你能点这个菜（权限校验），后厨会根据订单决定先做哪个菜、怎么做最优（优化器），最后炒菜师傅（执行器）用锅具（存储引擎）真正把菜做出来，再由配送员送回你手上。

这个类比虽然简单，但能帮你记住一个关键点：MySQL 不是一个“整体执行 SQL”的怪物，它是一套分工明确的流水线。你排查 SQL 慢的问题，本质上就是在排查流水线上哪一环出了问题。

1.2 为什么很多人以为“执行 SQL”就只是执行引擎在干活

我在带团队做数据库优化时，经常问一个问题：“SELECT 慢，你觉得是哪个环节慢？”大部分人会脱口而出“表数据太多了，索引没走”。这个回答没错，但不完整。索引选择是优化器的事，数据读取是执行器和存储引擎的事，而连接器如果出问题，SQL 甚至还没走到“查询”这一步就被卡住了。

举个很常见的例子：线上突然出现大量的Too many connections，你第一反应是谁在跑大查询，结果一查，发现是某个应用端连接池配置出错，把 MySQL 连接数打满了。这时候你优化 SQL 一点用都没有，因为请求根本没到达优化器。再比如，一个 SQL 语法本身有错误，或者访问了一个不存在的列名，它在解析器阶段就会直接报错，压根不会进入后面任何环节。

所以，理解一条 SQL 的执行过程，不是让你背面试题，而是让你具备一个能力：任何一次 SQL 异常，你能在脑海里快速定位到“这是哪一层的问题”。这句话是我这篇文章的核心目的。

2. 连接器：先证明你是谁，再谈执行

2.1 TCP 握手与鉴权细节

客户端要执行 SQL，第一步是建立连接。这里说的连接，底层是 TCP 连接，加上 MySQL 自定义的应用层协议。默认端口 3306，如果是本机 socket 连接，走的是/tmp/mysql.sock这类 Unix socket。

在这个阶段完成三件事：

• TCP 三次握手：建立网络通道。
• MySQL 协议握手：服务端发送握手包，包含协议版本、服务端版本、认证插件类型等；客户端回送认证响应。
• 身份与权限验证：MySQL 校验用户名、密码、来源 IP，并从权限系统里加载这个账号的全局权限、库权限、表权限、列权限，放到会话里留着后面用。

这里有个细节容易被忽略：认证插件。老版本 MySQL 默认是mysql_native_password，新版本从 8.0 开始默认成了caching_sha2_password。如果你用的是老驱动连接 8.0 的库，出现Authentication plugin 'caching_sha2_password' cannot be loaded这种报错，问题就出在握手阶段，和你的 SQL 半毛钱关系都没有。解决办法是升级驱动，或者给对应账号指定兼容的认证插件，但后者属于临时方案。

2.2 长连接与连接池的坑

MySQL 的连接是典型的“短连接成本高、长连接有隐患”。

每次新建连接，都要经过 TCP 握手、MySQL 握手、权限读取这三步。权限数据如果数据量大，加上网络 RTT，一个连接建下来几十毫秒很常见。所以业务层普遍使用连接池，比如 HikariCP、Druid、Spring 自带的池，目的就是复用连接，降低建连开销。

但长连接有一个非常经典的坑：连接状态一直挂在Sleep，占着服务器资源，却没有真正干活。

我见过一个生产事故：应用连接池配置了minIdle=50、maxActive=200，数据库max_connections=300。正常情况下没问题，有一天某个接口被刷，大量线程从池里拿连接执行慢 SQL，慢 SQL 不结束，池里的连接就不释放，新请求继续建新连接，很快把 300 个连接全占满。后面的请求排队等池子里归还连接，前端超时，于是重试又带来更多请求，最后数据库连接被占满，整个应用不可用。排查的时候第一眼看到的不是慢 SQL 本身，而是满屏的Too many connections。

所以连接层给你的经验是：连接数不是越大越好，池子大小、超时时间、连接验证策略三者必须一起调。池里的连接如果长期不用，MySQL 那边wait_timeout会自动断开，但连接池不知道，下次拿到一个死连接就会报Communications link failure。解决办法是在连接池配置里开test-on-borrow或者定时ping验证连接。

2.3 连接数限制和常见报错

SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';

max_connections是 MySQL 允许的最大连接数，Threads_connected是当前已用连接数。如果两者接近饱和，说明连接层已经告急。

常见的连接层报错有这几类：

排查连接问题时，优先用SHOW PROCESSLIST看每个连接在干什么：

mysql> SHOW PROCESSLIST; +----+------+-----------+------+---------+------+----------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+-----------+------+---------+------+----------+------------------+ | 5 | app | 10.0.0.1 | shop | Query | 120 | Sending data | SELECT * FROM ... | | 6 | app | 10.0.0.2 | shop | Sleep | 300 | | NULL | +----+------+-----------+------+---------+------+----------+------------------+

Command是Query说明正在执行 SQL；是Sleep说明空闲。Time越大越要警惕：Query时间过长是慢 SQL 占用资源，Sleep时间过长是连接泄漏不释放。看到这两种情况，首先确认是否存在连接池泄漏、事务未提交等情况，然后再看 SQL 本身。

3. 解析器与预处理器：SQL 从文本变成内部结构

3.1 词法分析和语法分析到底在干什么

连接建立之后，你发过来的是一条字符串，例如：

SELECT id, name FROM user WHERE age > 18 ORDER BY create_time DESC LIMIT 10;

MySQL 的解析器要做两件事。

第一件事：词法分析。把字符串拆成一个个 token，识别出哪些是关键字（SELECT、FROM、WHERE、ORDER BY、LIMIT），哪些是表名、列名、数值、字符串字面量。这一步是通过正则和状态机扫描实现的。你可以把它理解为把一整句话拆成一个个单词，并给每个单词标上词性。

第二件事：语法分析。根据 MySQL 的语法规则，把 token 流组合成一棵抽象语法树（AST）。这一步会检查语句结构是否合法：SELECT后面是否跟了列表达式，FROM后面是否跟了表名，WHERE后面是否跟了条件表达式，LIMIT后面参数是否合法，ORDER BY字段是否和SELECT列表冲突等。

语法分析阶段是最容易出传统报错的地方：

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ...

这个 1064 报错，本质上就是解析器在这里告诉你：语法树构建失败，我读不懂你的 SQL。常见的触发原因包括字符串引号不闭合、关键字拼写错误、语法升级前后写法不兼容（比如 8.0 之后窗口函数没写好）、括号不匹配等。

3.2 预处理器做的权限检查和元数据解析

语法树构建成功不代表万事大吉，接下来是预处理阶段，它做三件重要的事情：

• 检查表是否存在：FROM user中的user表在库中是否存在。
• 检查列是否存在：SELECT id, name中的id、name列是否存在于user表。
• 扩充权限验证：确认当前用户对user表有SELECT(id, name)的权限。这一步用的是连接建立时加载好的权限数据。

这里就要讨论一个非常容易混淆的问题：什么时候做权限校验？很多人以为权限校验发生在连接阶段，其实不是。

连接阶段只校验你能不能登录 MySQL。你登录成功后，能不能读某张表、能不能查某个列，要到预处理阶段查表结构时逐一校验。所以一个用户即使能连接到 MySQL，如果没被授权查询某张表，在执行SELECT * FROM secret_table时会在这一步直接报错：

ERROR 1142 (42000): SELECT command denied to user 'test'@'localhost' for table 'secret_table'

这个报错出现的位置，已经通过了连接器和语法检查，说明问题不是“连不上”，而是“没权限”。排查时需要检查授权：

SHOW GRANTS FOR 'test'@'localhost';

关于权限校验有个细节值得注意：列权限的校验发生在预处理阶段，但表权限的校验可能在优化阶段再次发生。特别是涉及视图的子查询时，MySQL 会递归校验视图对底层表的访问权限。如果你把一张表字段分列授权给某个账号，SELECT * FROM table会把没有权限的列也暴露出来吗？实测会发现它报错，而不是自动过滤。也就是说，MySQL 不会因为你没权限查某些列就只返回你有权限的列，它会在预处理阶段直接拒绝整条查询，避免“部分可见”带来的安全隐患。

3.3 常见解析阶段报错与排查

解析阶段报错的特征是：SQL 还没执行，直接返回。通过SHOW GLOBAL STATUS LIKE 'Queries'可以看到这一类请求其实也被计入 Queries 总量，但它们在SHOW PROCESSLIST中存活时间极短，很难被抓到。

排查这类报错，我建议直接从几个方向入手：

• 用EXPLAIN SELECT ...跑一遍，如果报语法错误，说明解析阶段就挂了。
• 检查字符串转义：'和\在拼接 SQL 时特别容易出问题。
• 检查是否用了 8.0 才有的语法跑到 5.7 的库上：比如WITH ... AS在 5.7 需要特定版本，WINDOW函数在 5.7 完全不可用。
• 检查表名/列名大小写敏感问题：Linux 上表名大小写敏感，列名不敏感，但代码里混用不同大小写风格容易埋坑。

解析器有个常被忽略的性能点：如果 SQL 文本非常长（比如批量拼接几千条 INSERT VALUES），解析器的 CPU 开销会明显上升。这也是为什么批量插入要控制单条 SQL 的 size，而不是无限拼接。解析再快，也是纯 CPU 工作，长文本的 token 化、AST 构建、元数据校验，都会变成执行链路里的固定成本。

4. 优化器：决定执行计划的“幕后黑手”

4.1 为什么同名 SQL 会有不同表现

解析器把 SQL 变成语法树之后，MySQL 知道你要干什么了，但“干什么”不等于“怎么干”。同一个查询，可能有多种执行路径：

• 全表扫描，把user表从头扫到尾。
• 走age列的索引。
• 走id主键索引后再回表。
• 如果有多个索引可以选，是走 A 索引还是 B 索引？
• ORDER BY create_time DESC是要排序，还是直接走create_time索引天然有序避免 filesort？
• LIMIT 10是否可以提前终止扫描，只取 10 行就返回？

优化器就是一个“决策者”，它在多个执行方案里挑一个它认为代价最小的。注意，是**“它认为”**，不是“绝对最优”。这是理解优化器最重要的一句话。

我见过一个真实案例：有个报表表里有idx_status和idx_create_time两个索引，SQL 是：

SELECT * FROM report WHERE status = 1 AND create_time > '2024-01-01' ORDER BY create_time DESC LIMIT 20;

优化器选的是idx_status先过滤status = 1，结果status = 1的行有几十万，回表再过滤时间，再排序，最终执行时间 15 秒。但如果我们强制走idx_create_time，倒序扫索引，最早命中 20 条记录就够了，执行时间不到 50ms。

这就是典型的优化器方案选择与预期不符。原因在于优化器的“神经”：它根据表的统计信息估算每个方案的代价，如果status = 1的区分度不准确（统计信息过期，或均匀度假设被打破），它就会算错代价，选错路径。

4.2 优化器如何算成本、选索引

MySQL 的优化器是基于成本的优化器，简称CBO。它给每个执行方案算一个总代价，包含：

• I/O 代价：读取数据页的数量。
• CPU 代价：过滤、排序、比较等操作的开销。
• 通信代价：数据传输回客户端的开销。

计算公式可以简化理解成：

总代价 ≈ 全表扫描代价 vs 索引扫描代价 + 回表代价 + 排序代价

全表扫描的代价取决于表的行数和页数；索引选择的代价则取决于：

• 索引的区分度：INDEX A每个值平均对应多少行，越少越好。
• 回表成本：走二级索引查出的主键，还要再回聚簇索引查完整行。
• 是否覆盖：如果SELECT的列都在索引中，可以直接走覆盖索引，减少回表。
• 排序列是否能借助索引天然有序：避免 filesort。

为了“猜”这些数字，优化器依赖存储引擎给出的统计信息。InnoDB 通过随机采样估算索引的基数（cardinality），如果采样时机不对，统计信息就会“过期”，导致优化器“误判”。

你可以用ANALYZE TABLE强制重新统计：

ANALYZE TABLE user;

注意，ANALYZE TABLE有锁的开销，别在业务高峰期频繁跑。

4.3 EXPLAIN 和 optimizer trace 实操

排查 SQL 执行计划，最常用的工具是EXPLAIN：

EXPLAIN SELECT id, name FROM user WHERE age > 18 ORDER BY create_time DESC LIMIT 10;

它的输出是执行计划的核心摘要。重点看几列：

看EXPLAIN的第一原则：不要只看有没有走索引，要看估算扫描行数和实际行数是否匹配。

我自己的习惯是：先看type。ALL是最坏情况，全表扫描；index说明扫描了整个索引，也不一定好；range说明走了索引范围扫描，通常是可控的；ref和const是较理想的等值匹配。再看Extra。Using filesort说明 MySQL 不得不额外做一次排序，如果排序列能走索引，往往可以消掉这一项。Using temporary说明中间结果建了临时表，常见于GROUP BY非索引列、DISTINCT复杂查询等场景。

当EXPLAIN只给了执行计划结果，但没告诉你“为什么”，这时候用Optimizer Trace：

SET optimizer_trace="enabled=on"; SELECT * FROM user WHERE age > 18 ORDER BY create_time DESC LIMIT 10; SELECT * FROM information_schema.OPTIMIZER_TRACE\G SET optimizer_trace="enabled=off";

OPTIMIZER_TRACE会把优化器的思考过程全部打印出来：它考虑了哪些索引，估算的成本是多少，为什么选了某一个。这个工具在排查“优化器选错索引”这类疑难问题时非常有用，比单纯看EXPLAIN更能定位原因。

4.4 索引失效的优化器视角

关于索引失效，网上有大量帖子讲“避免在索引列上进行函数运算”“避免隐式类型转换”等等。这里我从优化器的角度说一下为什么会这样。

索引本身是 B+ 树，节点是有序排列的。如果查询条件能转换成“索引列和一个常量做比较”，B+ 树就能用二分查找定位到某个范围。但如果你在索引列上套了函数，比如：

SELECT * FROM user WHERE DATE(create_time) = '2024-01-01';

优化器无法直接把DATE(create_time)这个表达式映射成create_time在 B+ 树上的有序范围，因为函数改变了值的排序规则。所以它只能放弃索引的范围查询能力，改而扫描整个索引或全表，行数一下子暴增。

优化器当然也可以尝试“改写”这类表达式来保留索引，但不是所有函数都支持改写。MySQL 8.0 在这方面有了改进，但核心原则仍然是：尽量让索引列保持原样，让函数作用在参数上。正确写法是：

SELECT * FROM user WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00';

再比如隐式类型转换。假设user.id是 VARCHAR，你写WHERE id = 100，数字 100 会被转成字符串再比较，还是字符串被转成数字？分情况。MySQL 规则是：如果比较的双方类型不一致，通常会把“字符串”转成“数字”再进行比较。如果索引列是字符串，转换后索引列的原本顺序就被打破了，优化器可能又只能放弃索引。

优化器在这里扮演的角色不是“故意坑你”，它只是在“无法可靠判断索引有效性”的时候做一个最保守的选择：扫描。所以排查索引失效，不要只看EXPLAIN结果，更要想清楚：这个查询条件到底能不能被 B+ 树利用上。

5. 执行器与存储引擎：数据到底从哪搬出来的

5.1 Server 层与存储引擎层的分工

优化器生成执行计划后，执行器开始“跑”这个计划。执行器在 Server 层，它本身不知道数据在磁盘还是缓冲池，不知道索引里的 key 怎么组织，它只知道“我要按执行计划去调用存储引擎的接口，拿回行记录，然后做 Server 层的后续处理”。

举个例子，执行计划告诉执行器：第一步，从user表的idx_age索引读取age > 18的第一行；第二步，通过主键回表取整行记录；第三步，看是否符合其他过滤条件；第四步，取下一行，直到满足LIMIT 10。

执行器就会一次次调用存储引擎接口：

• handler::ha_index_read()：按索引读取第一行。
• handler::ha_index_next()：按索引顺序读取下一行。
• handler::ha_rnd_pos()：按主键位置读取行。

存储引擎（InnoDB、MyISAM 等）才是真正干脏活累活的那一层：它决定数据页怎么缓存、索引怎么查找、行锁怎么加、事务怎么控制。

这个分层设计最有趣的代价是：Server 层和存储引擎层之间会有反复交互。MySQL 没有像某些数据库那样直接把执行器编译成存储引擎的原生指令，而是通过 handler 接口层的虚函数实现“通用化调用”。每读一行，就要从存储引擎跨越到 Server 层一次。如果扫描行数很多，这个“跨层”本身的调用开销也会叠加。

所以优化的一个重要思路就是：减少从存储引擎返回给 Server 层的行数。走索引、加过滤条件、控制LIMIT，本质都是在减少这个“跨层搬砖”的次数。

5.2 InnoDB 与 MyISAM 等引擎的执行差异

执行器是通用逻辑，但底层的存储引擎可以各显神通。

InnoDB（默认引擎）的特点是：

• 聚簇索引组织表：主键和数据行存在一起，二级索引的叶子节点存的是主键值。
• 支持事务、行锁、MVCC。
• 有缓冲池（Buffer Pool），读过的数据页缓存在内存里，下次读直接走内存。
• 数据页默认大小 16K，一次读取最少读一页。

MyISAM（老引擎）的特点是：

• 数据和索引分开存储，索引叶子节点存放指向数据行的物理地址。
• 不支持事务，锁表，崩溃恢复能力差。
• 在只读场景下扫描速度曾经有优势，但现在基本被 InnoDB 取代。

如果你在 5.7 之后的 MySQL 里新建普通表，默认就是 InnoDB。所以我们要聊的执行过程，严格说是“InnoDB 引擎下的执行过程”。

InnoDB 读数据的时候有个原则叫预读：它不会一次只读一个数据页，而是按照顺序预测要读的下一页，批量读入缓冲池。比如你全表扫描一张大表，执行器让 InnoDB 读“第一行”，InnoDB 会一口气预读一批数据页到缓冲池，后续的行读取大多直接命中内存。这也是为什么全表扫描有时候看起来“并不慢”——因为它在内存里连续搬数据，I/O 反而不是瓶颈。

但一旦数据量超过缓冲池大小，全表扫描就会频繁触发磁盘 I/O，表现就是Sending data状态持续很久。

5.3 没索引的行扫描到底发生了什么

假设你执行：

SELECT * FROM user WHERE age > 18;

如果user表没有age索引，也没有覆盖索引，执行器的计划就是全表扫描。InnoDB 会沿着聚簇索引（也就是主键顺序）从头开始扫描整张表，把每一行数据都返回给 Server 层，由 Server 层判断age > 18是否成立。

这里有个很容易忽略的点：即便age > 18一眼看过去过滤性很好，全表扫描也一点都“省事”。因为它必须把每一行读出来看一眼，哪怕只有 1% 的行满足条件，它也要扫 100% 的行。优化器在全表扫描和索引扫描之间算成本时，会拿预估行数、页数、过滤比例综合算账。有时它选择全表扫描，不是因为“笨”，而是因为表太小，走索引的额外开销（磁盘随机读、回表）反而更大。

判断走索引是否划算，可以参考rows估算。如果优化器预估要扫 100000 行，但type还是ALL，说明它认为全表扫更便宜。这时候你想人工干预，可以用FORCE INDEX：

SELECT * FROM user FORCE INDEX (idx_age) WHERE age > 18;

但注意，FORCE INDEX是让优化器优先考虑指定索引，而不是“强制使用”，如果该索引对该 SQL 完全不可用，MySQL 还是有可能选择其他方案。遇到这种情况，最好用IGNORE INDEX观察对比，而不是直接下狠手。

5.4 从执行器回 Query 结果到客户端的完整回路

最后一步是把结果集返回给客户端。这个环节有不少细节会影响体验，很多人忽略。

执行器拿到满足条件的行后，会按SELECT列表的列名组装数据。然后，MySQL 会把结果数据写进网络发送缓冲区，通过 MySQL 协议包分批传输给客户端。你可以用max_allowed_packet控制单次传输的最大包大小。

这里有几个实践要点：

• 大结果集不要一次性全捞出来。应用端做分页查询（LIMIT/OFFSET），数据库不仅扫描时减少返回行数，网络传输也减少。
• LIMIT 1000000, 20这种深分页是很差的做法。它要先把前 100 万行扫描出来丢掉，再取第 100 万行后的 20 行。优化方法是改用游标分页或记录上次最大 id。
• 结果集的组装和传输，也是执行器“忙碌”的时间。有时候你用SHOW PROCESSLIST看到一个 SQL 一直处于Sending data状态，其实就是执行器一边扫描、一边在往客户端推数据，可能卡在网络上了。

执行器这一步还会做一件事：记录慢查询日志。如果这条 SQL 的实际执行时间超过了long_query_time（默认 10 秒），执行器会在执行结束后写一条慢查询日志，记录时间、SQL 文本、扫描行数、返回行数等。注意，long_query_time的单位是秒，但判断标准是“实际执行时间”，不包括连接建立和等待锁的时间。

6. 查询慢真凶的排查思路：从一次实战说起

6.1 慢查询日志和分析

前面说了一大堆原理，最终都是为排查和优化服务的。我实际带团队排查慢 SQL，第一步永远是开慢查询日志，或者直接查 MySQL 里的slow log表。

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2; -- 设置超过2秒就记录 SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

然后可以用mysqldumpslow汇总慢日志，找到 Top N SQL：

mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

这条命令按耗时排序，展示前 10 条慢 SQL。也可以直接在表里查：

SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 20;

注意，mysql.slow_log这张表不是默认就维护的，需要在配置文件里打开输出到表，比较麻烦。生产环境一般直接看日志文件。

拿到慢 SQL 之后，我的标准动作是这样的：

1. EXPLAIN看执行计划，确认是否全表扫描、是否 filesort、临时表。
2. 看rows估算行数，和实际数据量对比，判断统计信息是否需要更新。
3. 看status字段里的Sending data状态持续时间。
4. 用OPTIMIZER_TRACE看优化器到底为什么选择当前计划。
5. 结合业务场景，决定是加索引、改写 SQL，还是调整参数（innodb_buffer_pool_size、max_allowed_packet等）。

6.2 同一张表、同一条 SQL 的不同环境表现

很多人问我同一个问题：同样的 SQL 在测试环境毫秒级返回，在线上却跑好几秒。这里最常被忽略的是环境差异。

我碰到过一个例子，测试库的表只有 5 万行，线上表有 800 万行。同一套 SQL：

SELECT order_id, user_id, amount FROM order_table WHERE status = 0 ORDER BY create_time DESC LIMIT 20;

测试环境走了idx_status，特别快；线上也走了idx_status，但 status=0 的行有 600 万，回表之后还要再排序，又因为create_time不是索引前缀，排序只能用 filesort，线上直接慢成狗。

这时候加一个联合索引就能解决：

ALTER TABLE order_table ADD INDEX idx_status_create (status, create_time);

为什么这个索引有效？因为status作为等值条件，create_time作为排序条件，联合索引天然让数据按 status 分组、组内按 create_time 有序。执行器扫描idx_status_create时，每一组的 create_time 已经排好序了，直接倒序取前 20 行即可，连 filesort 都省了。

这个案例说明：同一套 SQL 在不同数据分布下，执行计划完全可能不同。优化器是根据统计信息来决策的，统计信息又依赖实际数据，所以“原理够懂+实际看数据分布”才是排查慢 SQL 的正道。

6.3 我实际排查过的一个案例

再分享一个我自己遇到过的、不那么常规的案例。

某个系统的用户表user有 2000 万行，线上某条 SQL：

SELECT id, name, phone FROM user WHERE phone = '13800138000' LIMIT 1;

明明phone上有唯一索引uk_phone，EXPLAIN显示的type却是ref，rows估算只有 1，实际执行竟然要 800ms。一开始我不知道为什么，后来查OPTIMIZER_TRACE发现优化器认为走uk_phone的代价比全表扫描高，原因在于统计信息显示该索引的 cardinality 特别低——也就是说，优化器认为这个索引区分度很差，每个 phone 值对应很多行。可实际上 phone 基本是唯一的。

为什么统计信息会这么离谱？因为那张表之前经历过大批量DELETE + INSERT，InnoDB 的采样统计还没跟上。解决办法：

ANALYZE TABLE user;

跑了之后，执行计划自动改成const，SQL 瞬间回到 10ms 内。

这个案例有两点值得记到笔记里：

• 统计信息过期会骗过优化器，ANALYZE TABLE是重要的“纠正手段”。
• 排查执行计划，不要只信EXPLAIN的第一眼，要看rows是否符合预期，不符合时优先查统计信息。

MySQL 的统计信息更新机制是自动的，但更新时机依赖“变更行数超过一定阈值”。大批量操作后，主动ANALYZE是最可靠的做法。

7. 一些从执行链路延伸出来的优化习惯

前面讲清楚了一条 SQL 的完整执行路径，最后我想说的是：懂原理不是终点，能把原理用到日常工作中才是真正的收益。这里整理几条我从实践中沉淀下来的优化习惯，供你参考。

• 先确认瓶颈在哪一层，再动手优化。连接层问题调连接参数，解析层问题改 SQL 拼装方式，优化器问题更新统计或加索引，引擎层问题调 Buffer Pool 和 I/O 配置。不分层排查，很容易白费功夫。
• 慢 SQL 排查从执行计划入手，但执行计划只是“结果”。你要往前推一步，想想为什么优化器给出这个计划，这样才能根治问题。
• 索引不是越多越好，联合索引的顺序、选择性、回表成本都要算。很多团队为了“索引覆盖”疯狂加索引，最后写入变慢、存储膨胀，反而得不偿失。
• LIMIT深分页非常伤，分布式系统里提倡用 cursor 分页或异步流式拉取。
• 定期ANALYZE TABLE，特别是大批量导入、删除、更新之后。
• 所有 SQL 上线前，用EXPLAIN过一遍，并把rows和实际数据量做个对比。这个习惯几乎可以帮你避开 80% 的线上慢查询事故。

回到开头那句话：一条 SQL 的执行过程，听着是个偏原理和概念的话题，但它和我们每天遇到报错、排查慢查询、设计索引、评估性能是同一件事。你能在脑子里清晰画出从连接器到存储引擎的这条流水线，遇到问题时的直觉就会准得多，也不会再被“一条 SQL 慢”这个笼统现象带着跑偏。希望这篇分享对你有实际帮助。