文章目录
-
-
- [1. 优化器不是"法律条文"，而是"精算师"](#1. 优化器不是“法律条文”，而是“精算师”)
- [2. 临界点：到底选哪种？](#2. 临界点：到底选哪种？)
- [3. 拆解图中的例子](#3. 拆解图中的例子)
-
- [情况 A：`WHERE num NOT IN (1, 2)`](#情况 A：
WHERE num NOT IN (1, 2)) - [情况 B：`WHERE num NOT IN (3)`](#情况 B：
WHERE num NOT IN (3))
- [情况 A：`WHERE num NOT IN (1, 2)`](#情况 A：
- [4. 总结与口诀](#4. 总结与口诀)
- [💡 进阶思考](#💡 进阶思考)
-
这张图解释了 MySQL 优化器的一个核心灵魂：成本准则（Cost-based Optimization）。
很多人有个误区，觉得"NOT IN、!=、LIKE '%xxx' 肯定不走索引"。但实际上，MySQL 并不看心情，它只看数学。
为了让你彻底理解，我们要把这个逻辑拆成三层：
1. 优化器不是"法律条文"，而是"精算师"
MySQL 优化器在执行每一条 SQL 前，都会在后台算两笔账：
- 账本 A（走索引）： 先去二级索引找 ID，拿到 ID 后再去主键索引找整行数据（这个动作叫"回表"）。
- 账本 B（全表扫描）： 直接从头到尾把整张表的数据扫一遍。
重点来了：
二级索引是逻辑有序 的，但在磁盘上，回表去拿具体数据时往往是随机 I/O ；而全表扫描是顺序 I/O 。
对于磁盘来说，顺序读比随机读快得多。
2. 临界点：到底选哪种？
优化器会估算一个"比例"。
- 如果你的
NOT IN过滤掉绝大部分数据，只剩下 1% 的数据需要查。- 优化器想： "回表只要回 1% 的次数，不麻烦，走索引吧！"
- 如果你的
NOT IN只过滤掉一点点，剩下 90% 的数据都要查。- 优化器想： "我要回表 90% 的行，这得在磁盘上跳来跳去 90 万次，我不如直接花点力气把整张表顺序读一遍呢！"
3. 拆解图中的例子
假设表里有 200 万零几行数据：
num = 1：有 100 万行num = 2：有 100 万行num = 3：只有 5 行
情况 A：WHERE num NOT IN (1, 2)
- 含义： 实际上就是找
num = 3的那 5 行。 - 成本： 只需要通过索引找到这 5 行，然后回表 5 次。
- 结果： 走索引。因为数据量极小，回表成本几乎为零。
情况 B：WHERE num NOT IN (3)
- 含义： 实际上是找
num为 1 和 2 的那 200 万行。 - 成本： 要回表 200 万次！磁头会在磁盘上跳疯掉。
- 结果： 不走索引（全表扫描）。优化器认为顺序读这 200 万行比跳着读更快。
4. 总结与口诀
这个知识点其实在讲 "索引的选择性（Selectivity）"。
- 什么时候走索引？ 当过滤完剩下的数据**"少而精"**的时候。
- 什么时候全表扫描？ 当剩下的数据**"多而杂"**（通常超过全表的 20%~30%）的时候。
所以，不要记"NOT IN 不走索引"，要记"剩下的太多就不走索引"。
💡 进阶思考
如果你查询的字段就在索引里 （覆盖索引），不需要回表，那么哪怕 NOT IN 剩下 99% 的数据，它也依然会走索引。因为不需要回表，随机 I/O 的痛点消失了。