mysql如何优化索引以减少扫描_mysql高效索引设计原则

MySQL索引失效主因是最左前缀原则被破坏：范围查询或跳过中间列会导致右侧列无法使用索引；ORDER BY需满足最左连续列且排序方向一致；索引过多拖慢写入，应评估选择性与实际使用率；EXPLAIN中key_len和Extra比type更能反映索引使用情况。WHERE 条件里用不到索引？检查最左前缀是否被破坏MySQL 的 B+ 树索引生效前提是查询能从索引最左侧列开始连续匹配。一旦中间某列用了范围查询（>、>=、BETWEEN、LIKE 前缀不固定），右侧所有列就无法走索引了。比如有联合索引 INDEX (a, b, c)：WHERE a = 1 AND b = 2 AND c = 3 → 全部命中WHERE a = 1 AND b > 2 AND c = 3 → 只用到 a 和 b，c 被跳过WHERE a = 1 AND c = 3 → 只用到 a，c 完全失效（b 缺失导致断层）常见坑：把高频过滤字段放在联合索引右边，或者在中间列加了函数（如 WHERE YEAR(create_time) = 2024），直接让整条索引失效。ORDER BY 不走索引？确认排序方向和覆盖字段MySQL 要用索引做排序，必须满足两个条件：排序字段是索引的最左连续列，且所有排序方向一致（全 ASC 或全 DESC）。8.0+ 支持混合方向，但老版本不行。例如索引 INDEX (user_id, created_at)：ORDER BY user_id, created_at → 可走索引排序ORDER BY user_id DESC, created_at ASC → 5.7 及以前会触发 filesortORDER BY created_at → 即使有索引也用不上，因为没包含最左列 user_id额外注意：如果 SELECT * 且索引不是覆盖索引，MySQL 可能宁愿全表扫描 + filesort，也不走索引再回表——这时要权衡是否加 INCLUDE 字段或改写查询。索引太多反而拖慢写入？评估更新频率和选择性每多一个索引，INSERT/UPDATE/DELETE 就得多维护一份 B+ 树。尤其对高写入表（如日志、消息队列），索引数量应严格控制。 AI Code Reviewer AI自动审核代码