联合索引能提升多条件查询效率并避免排序和临时表使用。其核心优势在于支持多字段组合查询加速，且遵循最左前缀原则提高复用性。设计要点包括：1.顺序影响索引使用，高选择性字段放前面；2.遵循最左前缀原则，仅覆盖部分字段无法命中索引；3.避免冗余字段，控制索引长度；4.优先考虑区分度高的字段。适用场景如多条件查询、排序及分页查询。常见误区有：1.索引字段过多导致性能下降；2.忽视最左前缀原则；3.未分析实际查询模式；4.重复索引浪费资源。优化建议先分析慢查询日志或执行计划再建索引，确保索引合理有效。
在mysql中，联合索引（也叫复合索引）并不是简单地给多个字段各自加索引，而是将多个列组合成一个索引结构。这样做有很多优势，但也需要合理设计，否则可能适得其反。
为什么使用联合索引？
很多人一开始会为每个查询条件单独建索引，但这样往往效率不高。联合索引的核心优势在于可以同时支持多个查询条件的快速定位，并且在某些情况下还能避免排序和临时表的使用。
举个例子：如果你有一个订单表，经常根据“用户ID + 创建时间”来筛选数据，那么建立这两个字段的联合索引比分别建立两个单列索引更高效。
此外，联合索引的最左前缀原则也能提升查询复用性，这点后面再说。
联合索引的设计要点有哪些？
设计联合索引的关键在于理解你的查询语句，并遵循几个基本原则：
-
顺序很重要：联合索引是按列顺序构建的，所以哪个字段放前面会影响索引是否能被使用。通常把选择性高的字段放在前面。
-
最左前缀原则：比如你建立了（a, b, c）这个联合索引，那查询中如果包含 a、或 a+b、或 a+b+c 的条件，都可以命中该索引；但如果只查 b 或 c，则无法使用该索引。
-
不要盲目加字段：不是字段越多越好。索引越长，更新代价越高，占用空间也更大。
-
区分度优先：尽量把区分度高的字段放在前面。比如性别这种只有男/女的字段，就不适合做联合索引的第一个字段。
哪些场景适合用联合索引？
常见的适用场景包括：
- 多条件查询频繁的表，例如 WHERE user_id = ? AND create_time > ?
- 需要排序的场景，例如 ORDER BY user_id, create_time
- 分页查询时，如果已经有合适的联合索引，可以避免 filesort 和临时表
举个实际的例子：假设你有一个日志表，经常按照“操作人 + 操作时间”来查日志，这时候就可以考虑建立一个 (operator_id, operate_time) 的联合索引。
另外，在写 SQL 的时候也要注意，查询条件的顺序不一定非要和索引顺序一致，只要覆盖了最左前缀就能命中。
设计联合索引时容易踩的坑
有几个常见误区需要注意：
- ❌ 把所有查询字段都放进索引：这会导致索引膨胀，影响写入性能
- ❌ 忽视最左前缀：比如建了 (a,b)，但查询只用了 b，这时候索引就没用了
- ❌ 不分析查询模式：没搞清楚常用查询就建索引，可能导致索引利用率低
- ❌ 索引重复：比如已经建了 (a,b)，又建了 (a)，后者其实是多余的
建议在设计索引之前，先看一下慢查询日志或者执行计划（EXPLaiN），找出哪些查询没有走索引，再针对性优化。
基本上就这些。联合索引是个好东西，但要用对地方，不能乱建。掌握最左前缀、理解查询逻辑、结合实际业务场景，才是设计出高效索引的关键。
