复合索引的字段顺序为什么不能随便调换
MySQL 的 B+ 树索引是按字段顺序逐层排序的，
WHERE条件必须从左到右连续匹配索引字段，才能有效利用索引。比如建了
INDEX(a, b, c)，以下查询能走索引：
WHERE a = 1 AND b = 2 AND c = 3
WHERE a = 1 AND b = 2
WHERE 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一行命令解决。
