联合索引字段顺序不能随便换，因为B+树按定义顺序逐列比较，须遵循最左前缀原则：等值条件缺失或范围查询会截断后续列使用；排序、查询模式和选择性共同决定合理顺序。
联合索引字段顺序为什么不能随便换
MySQL 的 B+ 树索引是按定义顺序逐列比较的，不是“包含所有字段就高效”。一旦某列没用上等值条件（<code>= 或 IN），后续列就基本失效。
比如 INDEX (a, b, c)：
- WHERE a = 1 AND b = 2 ✅ 能用上 a 和 b
- WHERE a = 1 AND c = 3 ❌ c 不生效（b 被跳过）
- WHERE b = 2 AND c = 3 ❌ a 没出现，整个索引无法起步
- 最左前缀原则不是“语法限制”，而是 B+ 树搜索路径决定的物理行为
- 范围查询（
>,<,BETWEEN）会截断后续列——WHERE a = 1 AND b > 10 AND c = 5中 c 不走索引 - 排序需求也受顺序约束：
ORDER BY a, b可走(a,b)索引；但ORDER BY b, a就不行
怎么判断联合索引该按什么顺序排
核心看查询模式里「高频、高选择性、等值条件优先」的字段放前面。别只看单字段区分度，要看组合过滤后的实际效果。
例如用户表常查 WHERE status = 'active' AND city = 'shanghai' AND created_at > '2024-01-01'：
- status 只有 3–5 个值，选择性低，但几乎每条查询都带它 → 适合放第一列（保证索引能被命中）
- city 有几百个值，且和 status 组合后过滤掉 95% 行 → 放第二列很合适
- created_at 虽然时间戳区分度极高，但带范围条件 → 必须放最后，否则后面列全废
- 用
EXPLAIN看key_len：值越接近索引总字节数，说明用得越充分 - 注意隐式类型转换：比如
user_id是BIGINT，但查询写成WHERE user_id = '123'，会导致索引失效（字符串 vs 数字） - 如果既有
WHERE a = ? AND b = ?，又有WHERE b = ? AND c = ?，别硬塞进一个索引，考虑建两个：(a,b)和(b,c)
ALTER TABLE 调整联合索引顺序要小心什么
直接 DROP INDEX 再 ADD INDEX 不是原子操作，期间新索引不可用，还可能锁表（尤其在大表上）。
- 5.7+ 支持
ALGORITHM=INPLACE，但仅限添加/删除索引，不支持修改已有索引字段顺序 → 实质还是删+建 - 线上表 > 10GB 时，建议用
pt-online-schema-change或gh-ost，避免主从延迟或长事务阻塞 - 别忘了清理旧索引：
DROP INDEX idx_old ON tbl，否则冗余索引会拖慢写入性能 - 调整后务必查
information_schema.STATISTICS确认SEQ_IN_INDEX值是否符合预期
哪些场景下联合索引顺序优化收益不大
当数据量小（rows < 1000）、或查询本身已走覆盖索引、或表频繁更新导致索引维护成本反超查询收益时，调顺序意义有限。
-
SELECT *查询 + 联合索引未包含所有字段 → 还是要回表，顺序再好也难抵 IO 开销 - 写多读少的表（如日志表），加索引本身就要权衡，顺序只是次要问题
- 存在大量
OR条件或函数操作（WHERE YEAR(created_at) = 2024）→ 索引天然失效，调顺序没用
真正卡性能的地方，往往不在索引顺序，而在没走索引、统计信息不准、或执行计划被误导。先 EXPLAIN，再动索引。
