优化器基于成本模型评估发现，用主键索引顺序扫描并回表取数据的代价高于先用其他索引定位再排序，故放弃主键索引；典型场景是WHERE条件过滤性强但未与ORDER BY id组成联合索引，导致优化器选择更优路径。
为什么ORDER BY id LIMIT不走主键索引？
因为优化器发现：用主键索引顺序扫描 + 回表取数据，比用其他索引定位再排序更慢。它不是“放弃”，而是基于代价模型算出来主键索引这条路更贵。
典型场景是：WHERE条件过滤性好（比如uid = ? AND protocol_type = ?），但ORDER BY字段是id——而id和WHERE字段没组成联合索引。这时优化器会权衡：
- 走
idx_uid_protocol_no：先按索引快速定位几千行，再对这几千行做filesort（内存排序） - 走
PRIMARY：从主键开头一路扫，每行都要检查WHERE条件，可能扫几十万行才凑够LIMIT 1要的那1行
当估算出后者需要读的页数远超前者时，type=ALL就出现了——哪怕id是主键，也照扫不误。
EXPLAIN里key为空但type=index意味着什么？
这说明优化器选了主键索引做全索引扫描（type=index），但没把它当“查找索引”用，而是当“有序遍历通道”用——本质仍是全表扫描，只是走的是索引树叶子节点链表。
关键判断信号：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
-
key列为空或显示PRIMARY，但rows接近总行数 → 实际在扫全表 -
Extra里出现Using filesort→ 即使走了主键索引，仍要额外排序（因为WHERE过滤后剩余行不满足ORDER BY顺序） -
filtered值极低（如filtered=0.5）→WHERE条件几乎不筛数据，优化器直接放弃索引定位
怎么让ORDER BY id LIMIT稳定走索引？
核心思路：别让优化器在“索引定位+排序”和“主键扫描”之间做两难选择。有三条实操路径：
- 补联合索引：
ALTER TABLE t ADD INDEX idx_uid_proto_id (uid, protocol_type, id)—— 把WHERE字段放前面，ORDER BY字段放最后，实现覆盖查询+天然排序 - 改写
ORDER BY：如果业务允许，把ORDER BY id DESC换成ORDER BY created_time DESC, id DESC，并确保created_time上有高区分度索引 - 临时压制干扰：对单条SQL加
/*+ USE_INDEX(t, idx_uid_proto_id) */提示，但别长期依赖，它绕过成本模型，可能在数据分布变化后翻车
注意：ANALYZE TABLE必须做，否则Cardinality失真会让优化器持续误判；innodb_stats_persistent = ON建议开启，避免采样漂移。
为什么LIMIT 100, 20比LIMIT 0, 20更容易走错索引？
因为MySQL有个隐藏开关prefer_ordering_index，默认开启，但它会在offset + row_count超过阈值（通常5000左右）时自动失效。一旦失效，优化器就不再优先考虑“能避免排序”的索引，转而评估全表扫描成本。
验证方法：
- 执行
EXPLAIN FORMAT=JSON，查"using_index_for_order_by": false是否出现 - 对比
SELECT @@optimizer_switch，确认prefer_ordering_index=on - 临时关掉试试：
SET SESSION optimizer_switch='prefer_ordering_index=off'—— 如果关掉后反而变快，说明就是这个机制在起作用
真正棘手的点在于：这个阈值不固定，它受innodb_buffer_pool_size、临时表大小、甚至当前系统负载共同影响。线上压测时容易漏掉这点。
