复合索引是数据库优化中提升多条件查询效率的重要手段，但不少开发者在设计时往往凭经验随意组合字段，忽略了业务查询模式和WHERE条件实际出现频次，最终导致索引无法被有效使用，甚至拖慢写入性能。合理的复合索引需要以业务查询特征为核心，结合条件频次统计来设计，才能发挥最大作用。
一、先梳理业务查询模式
设计复合索引的第一步是收集所有涉及目标表的查询语句，尤其是高频访问的核心业务查询。需要整理出每个查询的WHERE条件组合、排序字段、分组字段，以及该查询的调用频率。例如电商订单表常见的查询模式可能有：按用户ID+订单状态查询、按商家ID+创建时间查询、按订单号精确查询等。
整理时可以用表格记录查询特征，方便后续分析：
| 查询场景 | WHERE条件组合 | 日均调用量 | 是否包含排序/分组 |
|---|---|---|---|
| 用户查自己的订单 | user_id, status | 120000 | 按create_time降序 |
| 商家查店铺订单 | shop_id, create_time | 80000 | 无 |
| 运营查异常订单 | status, create_time | 5000 | 按user_id分组 |
二、统计WHERE条件字段频次
梳理完查询模式后，需要统计每个字段在WHERE条件中出现的频次，以及不同组合的出现频率。频次越高的字段，越应该放在复合索引的前面，因为复合索引遵循最左前缀原则，前缀字段的匹配度越高，索引的适用范围越广。
统计时可以按以下步骤操作：
- 提取所有查询的WHERE条件字段，去重后列出字段列表
- 遍历每个查询，统计单个字段的出现次数，以及多字段组合的出现次数
- 结合调用量计算加权频次，高频调用的查询中的字段权重更高
比如上面的订单表例子，user_id出现频次120000，shop_id出现80000，status出现125000（120000+5000），create_time出现85000（80000+5000），那么单字段频次排序为status > user_id > create_time > shop_id。
三、结合频次设计复合索引
设计复合索引时，需要把高频字段放在前面，同时尽量覆盖更多查询场景。如果多个查询的条件组合有重叠，可以设计一个复合索引覆盖多个场景，减少索引数量。
还是以订单表为例，用户查订单的场景是user_id+status，运营查异常订单是status+create_time，这两个场景都包含status字段，且status频次最高，那么可以把status放在复合索引的第一位。如果用户查订单还需要按create_time排序，那么可以把create_time放在第三位，设计索引(status, user_id, create_time)，这个索引可以覆盖用户查订单的场景，也能被运营查异常订单的查询使用（因为最左前缀是status，符合最左匹配）。
如果商家查订单的场景调用量也很高，且条件是shop_id+create_time，和上面的索引组合没有重叠，那么可以单独设计第二个复合索引(shop_id, create_time)，避免用一个索引覆盖所有场景导致索引过长，影响写入性能。
四、验证索引有效性
索引设计完成后，需要通过执行计划验证是否生效。可以使用EXPLAIN命令查看查询是否使用了目标索引，以及索引的扫描行数。
以下是MySQL中验证索引的示例：
-- 查看用户查订单查询的执行计划 EXPLAIN SELECT * FROM order_table WHERE status = 1 AND user_id = 10001 ORDER BY create_time DESC; -- 查看商家查订单查询的执行计划 EXPLAIN SELECT * FROM order_table WHERE shop_id = 200 AND create_time >= '2024-01-01';
如果执行计划中type为ref或range，且key显示为目标索引，说明索引生效。如果type为ALL，说明全表扫描，需要检查索引设计是否符合最左前缀原则，或者WHERE条件中是否有索引字段的函数操作、类型转换等导致索引失效的情况。
五、常见设计误区
- 不要盲目把查询的所有字段都加入复合索引，索引过长会增加存储和维护成本，写入时性能下降更明显
- 不要忽略查询的调用频次，低频查询不需要专门设计复合索引，偶尔全表扫描的影响可以忽略
- 不要在复合索引中把范围查询的字段放在前面，比如把create_time放在索引第一位，那么后面的字段无法使用索引匹配
- 定期重新统计WHERE条件频次，业务迭代后查询模式可能变化，需要及时调整索引
合理的复合索引设计是一个动态过程，需要结合业务查询模式和条件频次不断调整，才能让索引真正服务于业务性能需求。