在MySQL中，联合索引（复合索引）的列顺序直接影响查询性能。合理的顺序能显著提升查询效率，而错误的顺序可能导致索引失效或效果大打折扣。核心原则是：根据查询条件的使用频率和选择性来安排列的顺序。
1. 将高选择性的列放在前面
选择性高的列指的是该列中不同值的数量（基数）多，重复值少。这样的列能更快地缩小查询范围。
例如，在一个用户表中，email 的选择性通常远高于 gender。因此，如果经常按 email 和 gender 查询，应将 email 放在联合索引的前面：
✅ 推荐：KEY idx_email_gender (email, gender)❌ 不推荐：
KEY idx_gender_email (gender, email)
2. 遵循最左前缀匹配原则
MySQL的联合索引遵循最左前缀匹配规则，即查询必须从索引的最左列开始，才能有效利用索引。
如果索引为
(A, B, C)，以下查询能命中索引：
WHERE A = ?
WHERE A = ? AND B = ?
WHERE A = ? AND B = ? AND C = ?
但以下查询无法完全利用该索引：
WHERE B = ?（跳过A）
WHERE B = ? AND C = ?（未包含A）
因此，应把最常用于过滤的列放在最左边，确保大多数查询能触发最左匹配。
3. 考虑排序和覆盖索引需求
如果查询中包含
ORDER BY或
GROUP BY，尽量让索引同时满足过滤和排序，避免额外的文件排序（filesort）。
例如：
SELECT name FROM users WHERE city = 'Beijing' ORDER BY age DESC;
此时创建
(city, age)索引，不仅能快速过滤城市，还能按 age 排序，实现索引覆盖，提升性能。
若只需查询索引中的字段，可进一步实现覆盖索引，直接从索引获取数据，无需回表。
4. 平衡查询模式与写入成本
虽然理想情况下希望每个查询都走高效索引，但过多或过长的联合索引会增加写操作（INSERT、UPDATE、DELETE）的开销，并占用更多存储。
建议：
分析慢查询日志，找出高频且耗时的查询 为这些查询设计针对性的联合索引 避免为低频查询创建复杂索引 定期审查并清理无用索引基本上就这些。关键是要结合实际查询语句、数据分布和业务场景来设计。可以用
EXPLAIN检查执行计划，确认索引是否被正确使用，不断调整优化。不复杂但容易忽略细节。
