复合索引字段顺序不能随意调换，因mysql b+树索引按字段从左到右逐层排序，where条件必须满足最左前缀原则才能生效；例如index(a,b,c)仅支持a、a+b、a+b+c组合查询，缺失a则无法使用该索引。
复合索引的字段顺序为什么不能随便调换
MySQL 的 B+ 树索引是按字段顺序逐层排序的，WHERE 条件必须从左到右连续匹配索引字段，才能有效利用索引。比如建了 INDEX(a, b, c)，以下查询能走索引：
WHERE a = 1 AND b = 2 AND c = 3WHERE a = 1 AND b = 2WHERE a = 1
但 WHERE b = 2 AND c = 3 或 WHERE c = 3 就完全用不上这个索引——因为缺失最左前缀 a。
常见错误是把高频过滤字段放在后面，比如用户总查 status 和 created_at，却建了 INDEX(created_at, status)，结果 WHERE status = 'done' 仍全表扫描。
哪些字段适合放进同一个复合索引
不是所有 WHERE 中出现的字段都要塞进一个索引。优先合并满足以下条件的字段：
- 经常一起出现在
WHERE条件中（如WHERE user_id = ? AND status = ?） - 有明确的筛选强度差异：高区分度字段（如
user_id）放前面，低区分度字段（如status、is_deleted）放后面 - 被用于
ORDER BY或GROUP BY，且顺序与 WHERE 字段可对齐（例如WHERE a = ? ORDER BY b, c可用INDEX(a, b, c)） - 避免重复建单列索引：如果已有
INDEX(a)，又建INDEX(a, b)，前者基本失效
如何创建和验证复合索引是否生效
创建语法很简单：ALTER TABLE t ADD INDEX idx_user_status_time (user_id, status, created_at);。但关键在验证：
- 用
EXPLAIN SELECT ...看key列是否命中索引名，rows是否显著减少 - 注意
type字段：出现range或ref是正常；ALL表示没用上 - 如果
WHERE含函数或类型隐式转换（如WHERE DATE(created_at) = '2024-01-01'），即使有索引也会失效 - 执行
ANALYZE TABLE t更新统计信息，避免优化器误判
覆盖索引场景下要不要包含 SELECT 字段
如果查询只涉及索引字段（如 SELECT user_id, status FROM t WHERE user_id = 123），且索引是 INDEX(user_id, status)，那么 MySQL 可直接从索引中取值，无需回表——这就是覆盖索引。此时可以考虑把常用查询字段加到索引末尾，但要权衡：
- 索引体积变大，写入变慢，缓冲池压力上升
- 只有当
SELECT字段固定、且查询频次高时才值得加；动态投影（如SELECT *）不适合 - 不要把
TEXT/BLOB类型字段加入索引，会报错或自动截断
真正难的不是语法，而是判断哪些查询模式稳定、哪些字段区分度真实足够、以及线上数据分布是否让索引在高峰期依然有效——这些没法靠 CREATE INDEX 一行命令解决。
