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）尽量放前面，它们能延续索引扫描 范围条件（
>、
、<code>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, 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部分，比凭经验猜靠谱得多。
