EXPLAIN显示type=ALL并非索引未建，而是优化器基于成本估算弃用索引：联合索引需满足最左前缀、避免范围查询中断、优先覆盖查询、统计信息准确、条件无函数或隐式转换。
EXPLAIN 显示 type=ALL，不是索引没建成功，而是优化器算完账后觉得走索引更慢。
联合索引没满足最左前缀，优化器直接跳过
MySQL 对联合索引的使用极其严格：必须从最左边的列开始连续匹配，中间不能断。哪怕只漏掉第一个字段，整个索引就形同虚设。- 查询
WHERE b = 1 AND c = 2，而索引是(a, b, c)→ 不命中，type=ALL - 查询
WHERE a = 1 AND c = 2（跳过b）→ 只能用上a，c无法走索引，过滤率差，优化器可能弃用 - 查询
WHERE a = 1 AND b > 10 AND c = 5→a和b可用，c因b是范围查询而失效（B+树中范围之后的列无法用于等值查找）
真正有效的模式只有：a、a,b、a,b,c 这三种前缀组合。
查询返回字段太多，回表成本压倒索引优势
联合索引本身不存所有字段，查SELECT * 必须回聚簇索引取数据。当预估要回表的行数较多时，优化器会认为不如直接扫一遍聚簇索引更省事。
- 索引
(status, user_id)，执行SELECT * FROM orders WHERE status = 1 - 若
status = 1占全表 40%，优化器估算要回表 60 万次 → I/O 开销远超全表扫描 - 但改成
SELECT status, user_id FROM orders WHERE status = 1→Extra=Using index，立刻走索引
所以“查什么”和“怎么查”同样关键：覆盖查询（所有字段都在索引里）是触发联合索引最稳妥的方式。
统计信息过期或基数严重失真
SHOW INDEX FROM t 里的 Cardinality 是采样估算值，不是真实分布。大批量导入或长期未更新后，它可能把低区分度字段（如 status）误报成高区分度，或反过来。
- 总行数 200 万，
Cardinality显示 190 万 → 优化器以为这个字段过滤性极强，实际只有 5 个取值 - 结果：建了
idx_status，但WHERE status = 1仍走全表扫描
验证方式：
-
SHOW INDEX FROM orders WHERE Key_name = 'idx_status_user'，看Cardinality是否合理 - 强制刷新：
ANALYZE TABLE orders（注意锁表，生产环境慎用） - 长期高频写入表建议开启：
innodb_stats_persistent=ON+innodb_stats_auto_recalc=ON
WHERE 条件里混入函数或隐式转换
哪怕索引列写得再标准，只要在条件里对它做了任何运算，B+树就无法直接定位。-
WHERE DATE(create_time) = '2026-07-01'→ 函数导致索引失效 -
WHERE mobile = 13812345678（mobile是VARCHAR）→ 隐式转换，等价于WHERE CAST(mobile AS SIGNED) = 13812345678 -
WHERE name LIKE '%张%'（前导%）→ 破坏前缀匹配能力
这类写法会让优化器彻底放弃该列上的任何索引，哪怕它是联合索引的第一列。
真正难排查的，往往不是“没建索引”，而是“建了但被悄悄绕过”。每一条 EXPLAIN 的 key 为空、rows 接近总行数、Extra 出现 Using where 而非 Using index，都在提示：索引存在，但没被信任。
