type=ALL 表示全表扫描，必须立即干预：检查索引是否生效、最左前缀是否匹配、避免函数/类型转换导致索引失效，并控制预读放大效应。
EXPLAIN 显示 type=ALL 就该立刻干预
只要 EXPLAIN 输出中 type 列是 ALL，说明这条查询正在全表扫描——不是“可能慢”，而是“必然抖动”，尤其在高并发或大表（千万行以上）场景下，I/O 瞬间拉满，TPS 波动剧烈。这不是等待优化的信号，是必须立即定位并切断的路径。
- 先确认是否真用了索引：检查
key列是否为NULL，若为空，索引根本没被选中 - 再看
rows估算值：若远超实际匹配行数（比如查 10 行却扫 200 万行），说明索引选择失当或统计信息过期 - 别信“数据量小所以无所谓”：InnoDB 的预读机制（
innodb_read_ahead_threshold、innodb_random_read_ahead）会基于扫描行为主动加载相邻页，小表全扫照样触发预读放大 I/O
联合索引列顺序错位是静默抖动源
复合索引 KEY idx_user_status_created(user_id, status, created_at)，但查询写成 WHERE status = 'active' AND created_at > '2025-01-01'，MySQL 无法使用该索引——type 直接退化为 ALL，且不会报错，只默默全扫。
- 最左前缀原则不是“建议”，是 B+ 树索引结构硬约束：必须从索引定义的第一个字段开始连续匹配
- 业务查询若长期只按
status过滤，这个索引实际无效；应补建KEY idx_status_created(status, created_at)或调整原索引顺序 - 注意
ORDER BY字段也参与最左匹配：若常查WHERE user_id = ? ORDER BY created_at DESC，则(user_id, created_at)比(user_id, status)更有效
函数/表达式让索引彻底失效，连预读都救不了
WHERE DATE(created_at) = '2026-04-20' 或 WHERE amount * 100 > 5000 这类写法，MySQL 必须对每行计算后再判断，索引列变成“不可比较值”，直接放弃索引走全表扫描。
- 改用范围等价写法：
created_at >= '2026-04-20 00:00:00' AND created_at - 数值运算反向推导：
amount > 50替代amount * 100 > 5000 - 隐式类型转换同理：
WHERE user_id = '123'（user_id是INT）会触发全表扫描，必须保持类型一致 - 预读机制在此类场景下反而有害：全表扫描触发线性预读（
innodb_read_ahead_type = linear），批量加载无用页，加剧 buffer pool 淘汰压力
InnoDB 预读本身不是问题，但会被全表扫描带崩
预读（read-ahead）是 InnoDB 自动加载相邻数据页的机制，分线性预读（linear）和随机预读（random）。它本意是加速顺序访问，但一旦落到全表扫描上，就成了性能放大器。
- 线性预读在连续扫描超过
innodb_read_ahead_threshold（默认 56）页时触发，一次预取 64 页——全表扫描几十万页？瞬间塞爆 buffer pool - 随机预读（
innodb_random_read_ahead = ON）更危险：当某区（extent）内有 13 个页被随机访问，就预取整个区的 64 页，极易误伤 - 临时缓解可关随机预读：
SET GLOBAL innodb_random_read_ahead = OFF，但治标不治本；根因仍是 SQL 或索引问题 - 真正稳定的调优点是控制扫描范围：用覆盖索引减少回表、用
SELECT明确字段避免*、用LIMIT截断非必要结果
真实线上抖动往往藏在“看起来能走索引”的查询里：比如 WHERE is_deleted = 0（低基数字段）、OR 连接无索引字段、LIKE '%关键词%'。这些不会立刻报错，但会在流量高峰时把预读机制变成压垮数据库的最后一根稻草。
