联合索引应优先将高选择性、高频查询的列置于左侧，遵循最左前缀原则，兼顾排序与覆盖需求，避免冗余以平衡读写性能。

在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 检查执行计划，确认索引是否被正确使用，不断调整优化。不复杂但容易忽略细节。