不是必须完全一致，但需满足最左前缀原则：查询条件须从复合索引最左列开始连续匹配等值条件，范围条件后字段无法使用索引，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 > '2024-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 部分，比凭经验猜靠谱得多。
