为什么 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的约束，无法定位起始位置。 范围查询（
>、
、<code>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综合判断。
