索引非万能，WHERE未用索引列、函数/隐式转换、返回大量行均致失效；复合索引需最左前缀连续匹配；覆盖索引可避免回表；唯一索引重在语义与锁优化；执行计划是否真实走索引才是关键。
为什么加了索引查询还是慢
索引不是万能的，WHERE 条件没用上索引列、用了函数或类型隐式转换、或者查询返回大量行，都会让索引失效。比如写 WHERE YEAR(create_time) = 2023，MySQL 无法使用 create_time 上的普通 B+ 树索引；又比如 WHERE user_id = '123'，而 user_id 是 INT 类型，字符串比较会触发隐式转换，导致索引跳过。
实操建议：
- 用
EXPLAIN查看type是否为ref/range，key是否显示实际使用的索引名 - 避免在索引列上做计算、函数调用、
LIKE '%xxx'开头匹配 - 确保查询条件的数据类型和字段定义完全一致（如
INT对INT，不是INT对VARCHAR）
复合索引的最左前缀怎么生效
MySQL 的复合索引（如 (a, b, c)）只支持从左到右连续匹配。这意味着它可以加速 WHERE a = ?、WHERE a = ? AND b = ?、WHERE a = ? AND b = ? AND c = ?，但对 WHERE b = ? 或 WHERE a = ? AND c = ?（跳过 b）无效。
实操建议：
- 把高频等值查询字段放最左，范围查询（
>、BETWEEN）字段放中间，排序/分组字段放最后 - 如果常查
status和created_at，但status只有 3 个值，而created_at高度离散，应建(status, created_at)而非反过来 - 不要盲目堆字段：超过 3 列的复合索引维护成本高，且命中率未必提升
什么时候该用覆盖索引
覆盖索引指查询所需的所有字段都包含在索引中，无需回表查聚簇索引。例如表有 id、name、email、status，而你执行 SELECT name, email FROM users WHERE status = 'active'，若存在索引 (status, name, email)，就能直接从索引页拿到全部数据。
