explain显示type=all并非索引未建，而是innodb优化器因函数使用、隐式类型转换或复合索引顺序不匹配主动放弃索引，导致全表扫描。
为什么EXPLAIN显示type=ALL，但明明加了索引？
这不是索引没建，而是InnoDB优化器“主动放弃”了它——常见于WHERE中对索引列用了函数、隐式类型转换，或复合索引顺序不匹配查询条件顺序。MyISAM遇到这类情况有时还能“硬用”，但InnoDB更严格，一旦发现无法做最左前缀匹配或索引失效，就直接退化为全表扫描。
-
WHERE DATE(create_time) = '2024-01-01'→create_time有索引也无效；应改写为create_time BETWEEN '2024-01-01' AND '2024-01-01 23:59:59' -
WHERE user_id = '123'（user_id是INT）→ 字符串字面量触发隐式转换，索引失效；必须写成user_id = 123 - 复合索引
(status, created_at)，但查询是WHERE created_at > '2024-01-01'→ 没用到最左列，索引被跳过
JOIN结果慢得离谱，InnoDB和MyISAM谁背锅？
MyISAM没有事务、无行锁、不支持外键，它的JOIN就是简单嵌套循环，执行路径固定；而InnoDB的优化器会基于统计信息估算成本，自动选择驱动表、连接算法（NLJ / BKA / Hash Join），但也更容易“选错”。尤其当表数据量突增、ANALYZE TABLE未及时更新时，优化器可能误判小表为大表，导致驱动顺序颠倒，性能暴跌数倍。
- 检查执行计划中
rows预估值是否严重偏离实际（比如预估100行，实际扫描50万行） - 强制指定驱动表：用
STRAIGHT_JOIN（仅限INNER JOIN），例如SELECT STRAIGHT_JOIN ... FROM small_table s JOIN large_table l ON ... - 避免在JOIN条件中混用不同字符集字段（如utf8mb4 vs latin1），会引发隐式转换，使索引失效且优化器失准
ORDER BY + LIMIT 10000,20卡住，InnoDB比MyISAM更难忍
InnoDB必须先按ORDER BY排完所有满足WHERE条件的行，再跳过前10000条——即使你只想要20条。MyISAM虽也慢，但因无MVCC和间隙锁，资源争抢略轻；而InnoDB在高并发下还叠加了undo log读取、版本链遍历开销，延迟更明显。
- 改用游标分页：
WHERE id > ? ORDER BY id LIMIT 20，前提是排序字段有索引且单调递增 - 若必须按非主键字段排序，可建覆盖索引+子查询定位起始点，例如：
SELECT * FROM t WHERE id IN (SELECT id FROM t WHERE status=1 ORDER BY create_time DESC LIMIT 10000, 20) - 避免
ORDER BY RAND()——InnoDB会为每一行生成随机数并全排序，MyISAM同样扛不住，但InnoDB额外付出MVCC开销
临时表和文件排序（Using temporary / Using filesort）在哪儿栽跟头？
InnoDB对临时表更“挑剔”：内存临时表（tmp_table_size和max_heap_table_size限制）一旦撑爆，就会落盘到InnoDB引擎的ibtmp1，而磁盘临时表远比MyISAM的.MYD/.MYI慢，且无法被缓存。更麻烦的是，GROUP BY或ORDER BY若无法利用索引完成排序，InnoDB必须走filesort，且不能像MyISAM那样用简单堆排序——它要兼顾事务可见性，排序过程更重。
- 确保
GROUP BY字段有索引，且顺序与索引最左前缀一致；否则必触发Using temporary -
ORDER BY a, b想走索引，索引必须是(a, b)，而非(b, a)或单独(a)（除非a是常量） - 监控
Created_tmp_disk_tables状态变量，持续升高说明内存临时表频繁溢出，需调大tmp_table_size
InnoDB优化器不是“更智能”，而是更依赖准确的统计信息和干净的查询写法；MyISAM看似简单粗暴，反而在某些固定模式下更可预期。真正容易被忽略的，是那些让优化器“看不懂”的细节：字符集混用、函数包裹、类型不一致、统计信息陈旧——它们不会报错，只会悄悄把你的查询拖进全表扫描的泥潭。
