数据库索引优化：复合索引的设计原则
数据库索引是提升查询性能的关键工具，而复合索引（多列索引）的设计更是优化中的核心难点。不合理的设计可能导致索引失效或资源浪费，本篇文章将系统阐述复合索引的设计原则，帮助开发者从原理到实践掌握优化技巧。
复合索引的核心：最左前缀原则
复合索引的底层数据结构（如B+树）按定义字段的顺序存储数据。查询时，数据库会从索引的第一个字段开始匹配，直到遇到范围查询或缺失字段为止。例如，索引(a, b, c)能高效搜索WHERE a=1、WHERE a=1 AND b=2，但无法利用索引优化WHERE b=2或WHERE c=3。这一原则是复合索引设计的基石。
在设计时，应将选择性高（即重复值少）的字段放在最左侧。例如，用户表中“邮箱”字段选择性远高于“性别”，索引(email, gender)优于(gender, email)。遵循这一规则，可以最大化索引的过滤能力，减少扫描行数。
避免冗余：索引合并与覆盖索引
复合索引的字段顺序直接影响查询效率。对于高频查询WHERE a=1 AND b IN (2,3)，应将等值条件字段a放在左侧，范围条件字段b置于其后。这样，数据库能快速定位到a=1的少量数据，再依次检查b值。若颠倒顺序，索引只能过滤b的范围，效率大幅下降。
覆盖索引是另一个重要设计原则：让索引包含查询所需的所有字段，避免回表访问。例如，查询SELECT a, b FROM table WHERE a=1，若已有索引(a, b)，数据库可直接从索引返回结果。添加冗余字段到索引时，需权衡写入性能，仅对高频查询的列进行覆盖。
复合索引的字段数量与顺序优化
索引字段并非越多越好。每个额外字段都会增加存储成本和写入开销，且可能降低查询优化器的选择效率。一般建议复合索引包含2-4个字段，超过5个时需谨慎评估。例如，电商订单表索引(user_id, order_time, status)已能覆盖绝大多数订单查询，添加“支付方式”等低选择性字段收益甚微。
字段顺序应遵循“等值条件优先，范围条件次之，排序字段最后”的原则。对于查询WHERE a=1 ORDER BY b，索引(a, b)既能过滤又能排序，避免文件排序。如果查询包含GROUP BY，同样将分组字段放在索引左侧，以利用索引有序性消除临时表。
实战案例：电商订单查询优化
假设订单表频繁执行SELECT * FROM orders WHERE user_id=123 AND status='paid' ORDER BY create_time DESC LIMIT 10。若仅有单列索引(user_id)，数据库需先过滤出所有user_id=123的记录（可能数千条），再在内存中排序并返回10条。优化方案是创建复合索引(user_id, status, create_time)：user_id和status作为等值条件前置，create_time用于排序。此索引可快速定位到少量数据，无需排序即可直接返回结果。
若查询改为WHERE user_id IN (123,456) AND status='paid'，则需将status放在user_id之前，因为IN条件会中断最左前缀。实际优化时，需结合业务查询模式，通过慢查询日志和EXPLAIN分析，反复调整索引组合。
总结：复合索引的黄金法则
复合索引设计的本质是平衡查询效率与维护成本。核心原则包括：遵循最左前缀、将高选择性字段前置、优先覆盖高频等值条件、控制索引字段数量（2-4个为佳）。实践中，应通过EXPLAIN命令验证索引使用情况，关注type为ref或range、Extra无Using filesort的理想状态。记住，没有万能索引，每个数据库索引优化方案都需基于实际查询模式定制。