加索引不等于查询快，是否走索引取决于条件写法与索引类型匹配度：LIKE ‘%abc’、函数查询、缺失最左前缀、顺序错位等均导致索引失效。
为什么 WHERE 条件用了索引，查询还是慢？
常见错觉是“加了索引就一定快”，但 MySQL 实际是否走索引、走哪个索引，取决于 WHERE 条件的写法和索引类型是否匹配。比如对 TEXT 字段建了普通 B-TREE 索引，却用 LIKE '%abc' 查询——这时索引完全失效；又或者对 JSON 字段建了 BTREE，但查询用的是 JSON_CONTAINS()，必须配合生成列 + 函数索引才有效。
-
LIKE 'abc%'可走 B-TREE 索引；LIKE '%abc'或LIKE '%abc%'无法使用前缀索引，除非改用FULLTEXT -
ENUM、SET字段用B-TREE效果好，但不支持全文检索 -
POINT类型字段必须用SPATIAL索引，B-TREE对其无效 - 对函数结果查询（如
WHERE YEAR(created_at) = 2024）会跳过索引，应改写为范围查询：WHERE created_at >= '2024-01-01' AND created_at
BTREE vs HASH：什么时候该选 MEMORY 表的哈希索引？
HASH 索引只存在于 MEMORY 引擎表中，且仅支持等值查询（=、），不支持范围、排序、前缀匹配。它在内存中做哈希查找，理论 O(1)，比 BTREE 的 O(log n) 更快——但前提是数据能全量放进内存，且查询模式高度固定。
- 适合场景：
SELECT * FROM cache_table WHERE id = ?这类高频、单键、无范围需求的缓存表 - 不能用于
ORDER BY或GROUP BY，MySQL 会直接忽略HASH索引并走全表扫描 -
BTREE是 InnoDB 和 MyISAM 默认索引类型，支持所有比较操作，绝大多数业务表应优先选它 -
HASH索引无法避免哈希冲突，高 并发 下锁竞争可能比BTREE更剧烈
复合索引的最左前缀原则不是“从左开始连续用”，而是“能推导出确定范围”
很多人记成“WHERE 必须包含第一个字段才能走索引”，其实更准确的理解是：MySQL 优化器能否利用索引结构逐层缩小搜索范围。例如索引是 (a, b, c)：
EXPLAIN SELECT * FROM t WHERE a = 1 AND b > 10 AND c = 5;这个查询会用到全部三列索引：先按 a = 1 定位索引块，再在该块内按 b > 10 做范围扫描，最后对每个满足 b 的记录检查 c = 5。但如果写成：
EXPLAIN SELECT * FROM t WHERE b = 10 AND c = 5;则整个索引失效，因为没有 a 的约束，无法定位起始位置。
- 范围查询（
>、、BETWEEN）之后的字段无法用于索引过滤，例如WHERE a = 1 AND b > 10 AND c = 5中，c不参与索引查找，仅用于回表后过滤 -
ORDER BY字段若出现在复合索引后缀中，且顺序一致、无混合 ASC/DESC，可避免文件排序（Using filesort） - 区分度高的字段建议放前面（如
status只有 3 个值，就不该放复合索引第一位）
ANALYZE TABLE 和 OPTIMIZE TABLE 不是“定期保养”，而是特定场景下的补救手段
InnoDB 表的统计信息（用于优化器选择执行计划）默认通过采样更新，当数据分布突变（如批量删掉 90% 记录）或执行计划明显劣化时，才需手动触发 ANALYZE TABLE。而 OPTIMIZE TABLE 实质是重建表（ALTER TABLE …… FORCE），主要解决碎片问题——但它会锁表，在大表上代价极高。
- 8.0+ 版本中，
innodb_stats_auto_recalc = ON（默认）且表变更行数超 10%，会自动更新统计信息 -
OPTIMIZE TABLE对已启用innodb_file_per_table的表，才能真正回收磁盘空间；否则只是整理页内碎片 - 频繁写入的表慎用
OPTIMIZE TABLE，可用ALTER TABLE t ENGINE=InnoDB替代，效果相同但更可控 - 真正影响性能的往往不是碎片，而是索引设计不合理或查询未覆盖——别把
OPTIMIZE当万能药
索引类型选错或查询写法绕过索引，比数据量大更常成为慢查根源。尤其是复合索引字段顺序、函数包裹条件、隐式类型转换 这些点，调试时容易被 EXPLAIN 的“key”列蒙蔽，得结合 key_len 和 rows 综合判断。
