17370845950

不是必须完全一致，但需满足最左前缀原则：查询条件须从复合索引最左列开始连续匹配等值条件，范围条件后字段无法使用索引，ORDER BY字段需紧接等值条件且方向一致。

WHERE 条件中字段顺序是否必须和复合索引顺序一致？

不是必须“完全一致”，但 MySQL 的 WHERE 条件能**高效利用复合索引的前提**，是它能匹配索引的最左前缀（leftmost prefix）。也就是说，如果建了索引 INDEX (a, b, c)，只有当查询条件包含 a（或 a AND b，或 a AND b AND c）时，索引才可能被用上；单独查 b 或 c 或 b AND c，这个索引基本无效。

常见错误现象：

EXPLAIN SELECT * FROM orders WHERE status = 'shipped' AND user_id = 123;

即使你为 (status, user_id) 建了索引，但如果实际高频查询是 user_id = 123 AND created_at > '2025-01-01'，那这个索引就无法覆盖——因为缺失最左列 user_id 的等值条件，而 created_at 是范围查询，会截断索引使用。

• 等值条件（=、IN）尽量放前面，它们能延续索引扫描
• 范围条件（>、、BETWEEN、LIKE 'abc%'）放在最后，一旦出现，其右侧字段无法参与索引查找
• ORDER BY 字段如果想避免 filesort，需紧接在 WHERE 等值条件之后，且顺序、方向（ASC/DESC）要匹配索引定义

如何判断当前查询是否真正用到了复合索引？

不能只看 EXPLAIN 的 key 列显示了索引名——关键要看 key_len 和 Extra。比如 key_len = 5 表示只用了索引前两个字节（可能是 TINYINT + CHAR(1)），而你本意是用三个字段，说明后半部分没生效。

典型误导场景：

EXPLAIN SELECT * FROM logs WHERE app = 'web' ORDER BY created_at DESC LIMIT 10;

若索引是 (app, level, created_at)，虽然 app 用了，但 level 没出现在 WHERE 中，MySQL 通常不会跳过它去用 created_at 排序——Extra 里大概率出现 Using filesort。

• 检查 key_len 是否符合预期（可用 SHOW CREATE TABLE 查各字段字节数累加验证）
• Extra 出现 Using index 表示覆盖索引，Using where; Using index 更理想；出现 Using temporary 或 Using filesort 就是性能隐患信号
• 对慢查询，用 SELECT ... FOR UPDATE 或高并发场景下，还要结合 SHOW ENGINE INNODB STATUS 看锁等待是否因索引不优导致

ORDER BY + LIMIT 场景下，复合索引怎么排字段？

这类分页查询最容易暴露索引设计缺陷。核心原则：让排序字段尽可能“紧跟”在所有等值过滤字段之后，并保持方向一致。否则 MySQL 不得不先扫出大量数据再排序，LIMIT 失去意义。

例如用户列表按创建时间倒序分页：

SELECT id, title FROM article WHERE category_id = 5 AND is_published = 1 ORDER BY created_at DESC LIMIT 20;

最优索引应为 (category_id, is_published, created_at)。如果写成 (created_at, category_id, is_published)，MySQL 无法用该索引同时满足过滤和排序——因为 created_at 是范围/排序字段，category_id 反而变成“中间跳过的列”，索引失效。

• 多个等值条件之间顺序影响不大（优化器可能调整），但建议把区分度高的放前面（如 user_id 比 status 区分度高）
• 如果 ORDER BY 含多个字段，如 ORDER BY a ASC, b DESC，MySQL 8.0+ 支持混合方向索引（INDEX(a ASC, b DESC)），但 5.7 及更早版本要求全部同向，否则退化为 filesort
• 避免在复合索引里包含大字段（如 TEXT、长 VARCHAR），会显著增大索引体积，降低缓存命中率

UPDATE / DELETE 语句也依赖复合索引顺序吗？

依赖，而且比 SELECT 更容易被忽略。因为 UPDATE 和 DELETE 的 WHERE 条件同样走索引查找路径，如果没用上合适索引，可能触发全表扫描+锁表，尤其在大表

上会直接拖垮数据库。

典型翻车点：

UPDATE user_profiles SET last_login = NOW() WHERE email = 'x@y.z' AND status = 'active';

如果你只建了 (status, email) 索引，而 email 是唯一性高、常用于单点查询的字段，这个索引效率远不如 (email, status)——前者需要先扫所有 status = 'active' 行再过滤 email，后者可直接定位到单行。

• 对高频更新的字段（如计数器、状态位），不要把它放在复合索引靠前位置，否则每次更新都引发索引树分裂
• UPDATE ... SET x = x + 1 WHERE ... 类操作，若 WHERE 条件没走索引，InnoDB 会升级为 next-key lock，阻塞相邻范围，引发连锁等待
• 用 pt-query-digest 抓取慢 UPDATE 日志时，重点看 Rows_examined 是否远大于 Rows_affected——这是索引未生效的强信号

索引顺序不是玄学，本质是配合 B+ 树的有序存储结构做数据定位。最危险的误区，是把「业务逻辑字段顺序」直接套用到索引定义上，而不看实际查询模式和条件组合。上线前用 EXPLAIN FORMAT=JSON 多看几遍 used_columns 和 range_analysis 部分，比凭经验猜靠谱得多。