SQL执行计划优化实战：三个案例让查询性能提升百倍

上个月线上订单中心有一条SQL查询，接口P99直接从600ms飙到4.8秒。我第一反应不是加缓存，而是先把执行计划拉出来看。结果发现一个很典型的问题：WHERE条件里的mobile字段在表里是VARCHAR，但程序传参传成了数字，MySQL做隐式类型转换后完全放弃索引，120万行全表扫描，2.4秒才出结果。改完SQL之后，同一句业务逻辑只用了0.018秒——100多倍的性能差距。这就是执行计划优化最吸引人的地方：不重写业务，不换数据库，只让查询优化器把路选对，性能就能天差地别。

说白了，执行计划就是数据库为一条SQL画的路线图。路线选错了，后面写再多的缓存、再加再多的机器都是白搭。这篇文章我整理了最近处理过的三个真实案例，分别是隐式类型转换、索引列上套函数、JOIN驱动表选错，每个案例都从线上现象、根因分析、优化动作、前后性能对比几个角度讲清楚。适合做后端开发、DBA、运维的同学阅读，特别是那些每次看到慢SQL只会kill session，或者一遇到性能问题就想着加机器的人。

1. 执行计划：SQL慢不慢，在数据库开口前就定了

1.1 执行计划是什么，为什么一张“路线图”能差出百倍

可以把查询优化器想象成一个快递调度中心。你写给它的SQL只是一句“我要从A点到B点”，但具体坐什么车、走哪条路、在哪个中转站换乘，都是由它决定的。执行计划就是它最终选定的配送方案。

同样的SQL，完全可能存在两种极端路线：一种是把全城所有包裹都翻一遍，挑出符合条件的那几件；另一种是通过楼层号、货架号直接定位到目标。全表扫描就是前者，索引查找就是后者。当数据量从十万涨到千万级时，这两种路线的成本差异会指数级放大。1000万行数据，全表扫描至少要把1000万行数据从磁盘拉出来，而走索引的查询可能只需要读取十几条记录就能返回结果。这个差距不是快一点慢一点，而是数量级上的鸿沟。

这也是为什么我一直强调，性能优化首先要看执行计划，而不是一上来就调参数或者升级硬件。机器的CPU快一倍，不会把一个全表扫描变成索引查找；但执行计划改对了，效果是几十倍、上百倍的提升。

1.2 我只看EXPLAIN结果里的这5个字段

MySQL里看执行计划最直接的方式就是EXPLAIN。我见过很多人执行完EXPLAIN之后，只看有没有用到索引，其他字段完全不管，这样其实漏掉了大量信息。我自己习惯重点关注5个字段：type、possible_keys/key、rows、filtered、Extra。

type字段反映了访问类型，性能从好到差大致是：const > eq_ref > ref > range > index > ALL。看到ALL就意味着全表扫描，这通常是慢SQL的第一个信号灯。possible_keys和key分别说明“优化器考虑过哪些索引”和“最终实际用了哪个索引”。如果possible_keys有值但key为NULL，说明有索引但没用上，这就是最值得深究的地方。

rows是优化器估算的需要扫描的行数，filtered表示过滤掉多少比例，两者相乘约等于最终返回的行数。Extra字段里的Using index是好事，说明覆盖索引直接搞定了；但看到Using filesort或者Using temporary就要警惕，说明排序或去重没能走索引，可能是个隐藏的性能隐患。另外MySQL 8.0还支持EXPLAIN ANALYZE，会真实执行SQL并输出实际耗时和行数，比单纯的EXPLAIN估算更接近真相，但生产环境跑大数据量时要谨慎。

1.3 为什么执行计划优化的收益远大于调参

很多同学喜欢一遇到性能问题就去调innodb_buffer_pool_size、max_connections、join_buffer_size这些参数。这些参数当然重要，但它们更像是“临门一脚”的性能兜底。如果执行计划本身就是错的，比如一个该走索引的查询走了全表扫描，你把buffer pool调到机器内存的上限，也不能让全表扫描变成毫秒级返回。优化器走错了路，你再怎么给路加油，走的总路程还是那么长。

我经常跟团队说一句话：先看路，再加油。执行计划是战略层，参数调优是战术层。战略错了，战术再好也是白搭。大部分SQL性能问题，根因往往就是三类：索引没建对、统计信息不准导致优化器选错、SQL写法让索引失效。这三个案例恰好覆盖了这三类问题。

2. 案例一：手机上多打了一个引号，120万行全表扫描

2.1 线上现象：同一个接口，白天和晚上是两个物种

业务背景是一张用户表users，大概120万行，线上有个“根据手机号查用户信息”的接口，晚上批量任务跑完后，这个接口的P99开始飙升，紧接着数据库CPU冲到100%，监控告警响了一排。查慢日志，发现慢SQL长这样：

sql复制SELECT id, nick FROM users WHERE mobile = 18812345678;

这SQL表面上看一点问题都没有，mobile字段上明明建了索引idx_mobile，按常理应该走索引，怎么可能慢到2.4秒？我把这条SQL单独拿出来EXPLAIN了一下，结果让我眉头一皱。

sql复制EXPLAIN SELECT id, nick FROM users WHERE mobile = 18812345678\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: users
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1245778
        Extra: Using where

type是ALL，rows估算124万，key是NULL。用户表全表扫了一遍，只为了查一个手机号。这放在任何一个业务里都是灾难级的性能事故。

2.2 定位根因：EXPLAIN一眼看到 type=ALL

我接着执行了show create table，确认mobile字段的定义是VARCHAR(20)，不是数字类型。问题一下就清楚了：SQL里的条件值是18812345678，一个整数，而mobile列是VARCHAR。MySQL有一条隐式类型转换规则：当字符串列和数字比较时，优化器会把字符串列转换为数字再比较，而不是把数字转换成字符串。

这个转换意味着什么？意味着索引列mobile上被套了一层CAST(mobile AS UNSIGNED)，索引列参与了计算，B+树原本的排序规则完全失效。优化器觉得这个索引已经没法用来定位数据，干脆全表扫描拉倒。

这类问题在代码里非常隐蔽。特别是在Java MyBatis这种半自动ORM框架里，如果实体字段定义成了Long，SQL参数就会以Long类型传给MySQL，看起来SQL完全正常，实际上已经在触发隐式转换。更可怕的是，字符串转数字的过程中一旦遇到开头不是数字的字符串，转换结果会变得不可控，查询结果都可能出错。

2.3 优化动作：让参数类型和列类型对齐

最直接的修复方式就是让SQL里的参数类型和字段类型保持一致。原本传数字，改成传字符串：

sql复制SELECT id, nick FROM users WHERE mobile = '18812345678';

改完之后再跑EXPLAIN，执行计划完全变样了：

sql复制EXPLAIN SELECT id, nick FROM users WHERE mobile = '18812345678\G
*************************** 1. row ***************************
         type: ref
possible_keys: idx_mobile
          key: idx_mobile
      key_len: 82
          ref: const
         rows: 1
        Extra: NULL

type变成ref，rows估算1行，key是idx_mobile。这条SQL从全表扫描变成了精准的点查。线上验证后，接口耗时从2.4秒降到0.018秒，直接提升了133倍。

这个案例里还有个细节值得说：如果业务上无法修改调用方传参类型，也可以反过来把mobile字段改成BIGINT。但手机号在不少业务场景里可能带+号、空格等字符，改数字类型之前一定要想清楚是否真的安全。我的建议是优先改SQL，而不是改表结构。

2.4 延伸：如何提前发现这类隐式类型转换

这类问题靠监控告警来发现，其实已经晚了。更好的做法是主动排查。我每周会跑一次TOP慢SQL分析，把慢日志里rows估算高、key为NULL的SQL捞出来，批量EXPLAIN一遍。看到possible_keys有值但key是NULL的，基本都有一个隐式类型转换或者函数包裹的问题在等着。

另外还有一个技巧：MySQL的information_schema里没有现成的“隐式转换检测”视图，但你可以通过对比SQL文本和表结构来推断。比如SQL里入参明明是数字，而表结构字段是VARCHAR，这种不匹配就是高发信号。还可以关注performance_schema里的events_statements_summary_by_digest，把执行次数多、平均耗时高的语句摘出来，重点分析执行计划，比等线上慢查询告警要主动得多。

3. 案例二：DATE函数让索引“原地失效”，800万行8秒变0.07秒

3.1 业务场景：统计某日下单金额

第二个案例是订单中心的报表业务。orders表有800万行，业务方要在运营后台查看某天的下单金额和单量，SQL长这样：

sql复制SELECT COUNT(*), SUM(order_amount)
FROM orders
WHERE DATE(create_time) = '2024-06-01';

create_time字段上有索引idx_create_time。但这条SQL跑一次要8秒多，运营后台页面直接超时，用户反复点刷新，数据库连接被打满。我接手的时候，第一个想法是：看起来就查一天的订单，怎么会扫全表？

EXPLAIN结果印证了我的判断：

sql复制EXPLAIN SELECT COUNT(*), SUM(order_amount)
FROM orders
WHERE DATE(create_time) = '2024-06-01'\G
*************************** 1. row ***************************
        table: orders
         type: ALL
possible_keys: NULL
          key: NULL
         rows: 7964120
        Extra: Using where

800万行，全表扫描。索引idx_create_time明明存在，但possible_keys直接是NULL，连考虑都没考虑。

3.2 根因：函数包裹列之后，B+树无从下手

这个问题的根因和案例一本质上是同一类：索引列被函数给“包装”了。DATE(create_time)会在create_time的每一个值上先执行一次函数计算，再拿计算结果去跟等号右边的字符串比对。但B+树索引里存储的是原始create_time值，索引的排序规则基于原始值，函数处理之后的值和索引顺序完全对不上，优化器当然没办法拿它做快速定位。

这里可以打个比方。别人给你一本按姓氏笔画排列的通讯录，你要找“张三”，正常情况下直接翻到“张”字开头的位置就行。但如果你要求先把所有人的姓氏取出来做一次转换，再按转换后的值找，那通讯录原有的顺序就全失效了，只能从第一页翻到最后一页。

DATE(create_time) = '2024-06-01'这一句看起来没毛病，实际上就是让B+树索引“原地失效”。优化器连索引都不想用，因为它知道用了也白用。

3.3 改写SQL：从等值函数变成区间条件

这类问题的标准解法就是不碰列，把条件改写成范围查询。DATE(create_time) = '2024-06-01'的语义，本质上就是create_time落在'2024-06-01 00:00:00'到'2024-06-02 00:00:00'之间。改成这样：

sql复制SELECT COUNT(*), SUM(order_amount)
FROM orders
WHERE create_time >= '2024-06-01 00:00:00'
  AND create_time <  '2024-06-02 00:00:00';

create_time没有经过任何函数处理，索引就能正常走。EXPLAIN之后：

sql复制EXPLAIN SELECT COUNT(*), SUM(order_amount)
FROM orders
WHERE create_time >= '2024-06-01 00:00:00'
  AND create_time <  '2024-06-02 00:00:00'\G
*************************** 1. row ***************************
        table: orders
         type: range
possible_keys: idx_create_time
          key: idx_create_time
         rows: 859
        Extra: Using index condition

type从ALL变成range，rows从796万降到859，耗时从8.2秒降到0.07秒，提升约117倍。这个数字在报表场景里是很典型的：从用户完全无法忍受，变成点开页面秒出数据。

改写的时候有一个边界条件要格外注意：右边界必须用<而不是<=。因为DATE(create_time) = '2024-06-01'只包含当天的零点到23:59:59，如果create_time是DATETIME类型，'2024-06-02 00:00:00'这条数据并不属于当天，所以右边一定是开区间。另外，如果你的表里存的是TIMESTAMP类型，还要考虑时区转换对边界值的影响，避免因为数据库时区和业务时区不一致导致统计结果差一天。

3.4 什么时候可以用函数索引

有些场景下SQL不是你能改的，比如第三方平台的查询。MySQL 8.0.13之后支持了函数索引，针对这类问题可以直接给表达式建索引：

sql复制ALTER TABLE orders ADD INDEX idx_create_time_date ((DATE(create_time)));

这样就算SQL里仍然写着DATE(create_time) = '2024-06-01'，优化器也能通过idx_create_time_date快速定位。但我个人建议慎重使用函数索引：它本质上是把计算结果冗余存储一份，写放大是实打实的。如果一张表高频插入更新，函数索引反而会增加压力。更常见的做法还是，通过SQL改写和范围条件来解决，不要一上来就往表上加索引。

生成列是另一个折中方案，MySQL 5.7就支持在虚拟列上建索引，可以理解为函数索引的老版本实现。但不管是函数索引还是生成列索引，都意味着数据库里多了一份冗余数据，能不改SQL就优先改SQL，改不了SQL再考虑这些高级特性。

4. 案例三：JOIN驱动表选错，2000万行白白扫一遍

4.1 一张1万行的会员表，为什么被当成2000万行

第三个案例是一个线上联表查询。会员表member有1万行，消费流水表consume有2000万行，需求是查所有黄金会员的昵称和消费金额。表结构很清晰：member表的主键是id，level字段表示会员等级；consume表上有idx_member_id索引指向member表的id。最初的SQL长这样：

sql复制SELECT m.member_name, c.total_amount
FROM consume c
JOIN member m ON c.member_id = m.id
WHERE m.level = 'gold';

按照“小表驱动大表”的常识，这条SQL应该先扫member表，把level='gold'的会员筛出来，再逐条去consume表通过idx_member_id查消费记录。但线上执行时间到了8秒多，明显不对劲。

EXPLAIN结果是这样的：

sql复制EXPLAIN SELECT m.member_name, c.total_amount
FROM consume c
JOIN member m ON c.member_id = m.id
WHERE m.level = 'gold'\G
*************************** 1. row ***************************
        table: consume
         type: ALL
         rows: 20000000
*************************** 2. row ***************************
        table: member
         type: eq_ref
         key: PRIMARY
         rows: 1

第一行是consume表，type=ALL，rows=2000万。这说明consume表被当成了驱动表，先把2000万行数据全部扫了一遍，然后每扫一行，都拿着member_id到member表的主键上做一次查找。等于嵌套循环了2000万次。虽然member表的每次主键查找速度很快，但2000万次循环累积起来就是秒级响应。

真正让我意外的是：member明明只有1万行，为什么优化器选了2000万行的consume做驱动表？看了information_schema.tables里的TABLE_ROWS字段，真相大白。

sql复制SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = 'your_db'
  AND table_name IN ('member','consume');

member表的TABLE_ROWS显示大约是1500万，而不是实际的1万。这就是典型的统计信息过期。之前有一批数据迁移脚本在半夜跑挂了，member表的数据被回滚清掉了大半，但统计信息没有跟着重新计算。优化器在看执行计划的时候，以为member表里有1500万行，用小表驱动大表的常识就反过来了：它以为member表才是大表，选了consume做驱动表，结果就是灾难。

4.2 优化动作：更新统计信息 + 补索引

这类问题的修复路径很清楚。第一步先让优化器看到真实数据：

sql复制ANALYZE TABLE member;

ANALYZE会重新采样并刷新InnoDB的统计信息。执行完之后再跑EXPLAIN，优化器已经能把member识别为小表，自动切换驱动顺序。但光靠ANALYZE还不够稳，因为member表的level字段当时没有索引，优化器对level='gold'的过滤行数估算精度不高。为了给优化器更准确的依据，我顺手补了一个索引：

sql复制ALTER TABLE member ADD INDEX idx_level (level);

有了这个索引之后，优化器可以非常准确地知道level='gold'对应多少行，执行计划顺利变成member作为驱动表，先通过idx_level过滤出黄金会员，再逐条到consume表通过idx_member_id做ref查找。

sql复制EXPLAIN SELECT m.member_name, c.total_amount
FROM consume c
JOIN member m ON c.member_id = m.id
WHERE m.level = 'gold'\G
*************************** 1. row ***************************
        table: member
         type: ref
         key: idx_level
         rows: 458
*************************** 2. row ***************************
        table: consume
         type: ref
         key: idx_member_id
         rows: 9

这回驱动表是member，先过滤出458个黄金会员，再分别去consume表查每个会员的消费记录，每次通过idx_member_id定位到大约9条。整个嵌套循环从2000万次降到了4000多次，查询耗时从8.1秒降到0.055秒，提升约147倍。

4.3 STRAIGHT_JOIN这种“手术刀”怎么用

有些情况下，就算统计信息更新了，优化器仍然会因为cost模型算错而选错驱动表。这时候可以临时用STRAIGHT_JOIN来强制指定连接顺序：

sql复制SELECT m.member_name, c.total_amount
FROM consume c
STRAIGHT_JOIN member m ON c.member_id = m.id
WHERE m.level = 'gold';

STRAIGHT_JOIN的作用是让左边的表作为驱动表，右边的表作为被驱动表。上面这个写法强制consume做驱动表，一般只是用来验证“如果选错驱动表是否真的会导致慢查询”，不建议直接上生产长期使用。因为一旦数据分布变化，手写死的连接顺序很可能变成下一个性能瓶颈。

我的建议是：STRAIGHT_JOIN是手术刀，不是大补丸。排障时拿来验证假设可以，但最后的修复方案一定要回归到让优化器自己选对。优化的本质是给优化器提供足够好的信息，而不是替它做所有决定。统计信息准确、索引合理、SQL写法没有诱导性，优化器大多数情况下都会给出很合理的执行计划。

4.4 一个额外细节：GROUP BY的临时表问题

原本的报表需求还带了一个GROUP BY m.member_name，优化后会看到Extra里出现Using temporary; Using filesort。这是因为member_name没有索引，分组排序只能走临时表文件。这个问题如果数据量继续涨，还可能成为新的瓶颈。

如果需求只是统计每个黄金会员的消费总额，更好的方式是让成员表的主键和分组字段统一，或者把GROUP BY改成GROUP BY m.id。分组字段和索引匹配之后，才能彻底避免Using filesort。这一点在做JOIN优化时经常被忽略，很多人看到执行计划从ALL变成ref就以为大功告成，实际上带着一个上万行的临时文件排序，后续还是会出问题。

5. 执行计划优化的通用排查路径与避坑清单

5.1 三层排查法：从SQL、表结构到统计信息

处理了这么多年慢SQL，我总结出一个三层排查法，基本能覆盖绝大多数执行计划相关的问题。第一层是SQL文本层：看WHERE条件、JOIN条件、ORDER BY/GROUP BY字段上是不是有函数包裹、隐式类型转换、前导通配符、OR拼接等问题。第二层是表结构层：看索引是否合理，字段类型是否匹配，有没有覆盖索引的机会，是否缺了关键索引。第三层是统计信息层：看TABLE_ROWS和真实数据量是否严重偏差，直方图有没有建立，优化器有没有被过期统计信息误导。

这三层不是并列关系，而是递进关系。我见过很多人第一个想到的是去改optimizer_switch这类优化器开关，其实绝大多数问题到不了这一步，SQL和表结构层面就已经能解决。真正需要动优化器开关的场景非常少，动之前必须要有明确的验证闭环。

排查时我习惯用EXPLAIN ANALYZE再确认一轮，因为它能输出每个操作的实际耗时和循环次数。比如看到Nested loop inner join的实际总耗时，结合EXPLAIN里的rows估算，能很快判断问题是出在驱动表选错，还是内部回表太多。

5.2 常见慢SQL速查表

这个速查表我一直贴在工位上，每次