1. 了解联合索引与复合索引的基本概念
在 MySQL 的设计中，联合索引与复合索引通常指在同一个索引结构中按一定顺序保存多列信息的场景，这种索引能够在多列条件同时出现时提升查询效率。理解它们的工作机制，是实现高效查询的第一步。多列组成的索引并不等同于简单的单列索引叠加，二者在使用规则上存在本质差异。
本节要点包括：左前缀原则、索引的列顺序对查询覆盖与跳转的影响，以及在不同查询模式下的应用范围。只有明确了这些概念，才能在后续设计中有针对性地选取列及其顺序。SQL 语句中正确创建复合索引是实现策略的落地步骤。
CREATE INDEX idx_user_name_email ON users(name, email);在实际设计中，联合索引的列顺序会直接决定哪些查询可以走索引，以及能否实现覆盖查询。若包含的条件未能覆盖前缀列，则可能触发回表操作或全表扫描，因此需要结合实际查询模式来确定顺序。初始设计阶段应尽量以常见查询路径为导向，避免在后续变更中产生低效的走索引情况。
2. 2. 左前缀原则与排序规则
2.1 左前缀原则
左前缀原则描述为：对一个由多列组成的索引，只有 WHERE 条件中包含该索引最左边的若干列时，MySQL 才能够使用该索引进行定位。如果条件缺少了最左边的列，或者只匹配到中间的列，则大多情况下无法有效利用该复合索引。该原则决定了查询写法与索引设计是否匹配。
在实际开发中，若存在多种查询路径，务必确保最常用的路径满足左前缀条件，以保证高频查询的索引命中率。若经常出现跨越索引前缀之外的组合查询，可能需要额外添加辅助索引或调整现有索引顺序以提升性能。
SELECT id, name FROM orders
WHERE customer_id = 123 AND status = 'OPEN';上述查询若对应的复合索引为 (customer_id, status, created_at)，则前两个条件刚好覆盖了最左前缀，从而实现索引走访。否则，若只有 status 或 created_at，则索引命中将显著降低。
2.2 列顺序对查询性能的影响
列顺序不仅影响是否能使用索引，还影响是否能覆盖查询。覆盖索引意味着查询所需的字段全部在索引中即可返回，不需要回表访问原表，极大提升性能。
在设计时，应优先把高基数、筛选性强的列放在前面，例如日期区间中的筛选、状态位等，这能提高命中概率并提升覆盖度。高基数列放在前往往比低基数列放前更有效，但也要结合实际查询场景进行综合判断。
CREATE INDEX idx_order_filter ON orders(customer_id, status, order_date DESC);通过以上设计，若大部分查询都包含 customer_id 与 status，且仅需 order_date 进行排序或过滤，则该组合更容易实现覆盖，降低 I/O 开销。
3. 3. 覆盖查询与实战设计
3.1 覆盖索引的概念与实现
覆盖索引指的是查询所需的字段全部包含在索引本身中，从而避免对基表的回表操作。实现覆盖索引的关键在于：选择合适的列组合，使 WHERE、JOIN、ORDER BY、SELECT 的字段尽量落在同一索引内，并且避免在选择列中引入未被索引覆盖的字段。
在设计阶段，通常会构造包含经常被访问的字段的复合索引，以实现尽可能多的覆盖路径。若能覆盖大部分查询场景，则能显著降低磁盘 I/O 与随机访问开销。覆盖能力是衡量复合索引设计优劣的重要指标之一。
EXPLAIN SELECT name, email FROM users
WHERE country = 'CN' AND status = 'ACTIVE'
ORDER BY created_at DESC;结合 Explain 结果可以看到，若上述查询走了索引而无需回表，则说明覆盖效果良好。若存在回表趋势，则需要重新评估索引列的组合与顺序。
3.2 结合查询场景进行索引设计
在实际项目中，查询场景往往具有多个维度，如用户地域、状态、时间等。通过分析日志与查询计划，可以逐步构建一组“主索引 + 辅助索引”的设计体系来覆盖核心场景。以最热查询路径为优先，再逐步扩展到边缘场景。
常见设计模式包括：将筛选性强的字段放在前缀、在需要排序的字段上添加方向性描述、以及在组合查询中强制使用前缀来保证走索引。下面的示例展示了一个典型的设计思路，涵盖用户表在地域、状态及时间维度上的查询需求。
CREATE INDEX idx_user_activity ON users(country, status, last_login DESC, id);4. 4. 复合索引在写入性能中的代价与维护要点
4.1 插入/更新的维护成本
创建复合索引会引入额外的写入开销，因为在每次插入、更新或删除时，数据库需要同步更新索引结构，这会增加写入延迟。对于写密集型表，需权衡查询性能提升与写入成本增加之间的平衡。
在设计阶段，可以通过分离高写入成本的列、减少不必要的复合索引、以及采用分区策略来降低写入成本的影响。理解这种成本权衡，是长期性能稳定的关键。定期评估查询计划的执行计划变化，以决定是否需要调整索引。
ALTER TABLE orders ADD INDEX idx_order_customer_status (customer_id, status);对于已经存在的表，新增或修改索引都需要在低峰期执行，以降低对线上业务的影响。备份与回滚策略也应在计划变更前就位，确保可控的风险。
4.2 索引分割与分区的用法
在数据量极大的场景中，结合 分区表 与 复合索引，可以降低单次查询的扫描范围、提升局部性访问效率。通过分区条件先行过滤，再在分区内部执行索引查找，通常能够获得更好的性能边界。
常见做法包括将时间序列数据按日期分区，或按地域、客户组等维度进行分区，以便在最新数据上快速定位，同时保留历史数据的可查询性。分区策略需与查询模式紧密对齐，以避免分区裁剪失败导致的扫描增多。
ALTER TABLE events PARTITION BY RANGE (event_date) (PARTITION p202101 VALUES LESS THAN ('2021-02-01'),PARTITION p202102 VALUES LESS THAN ('2021-03-01')
);5. 5. 实战设计要点
5.1 实战案例：订单表与查询路径设计
在一个典型的电商订单场景中，订单表包含字段如 id、customer_id、order_status、created_at、region 等。为高频查询路径设计组合索引时，优先考虑常见筛选条件的组合，例如 (customer_id, order_status)、(region, order_status, created_at) 等。
一个常见的设计原则是：将高基数且过滤性强的列放在前端，以提高前缀命中率，并尽量让常见查询路径成为覆盖索引。以下是一个典型的实现示例，适用于按地区与状态过滤并按创建时间排序的场景。覆盖性与排序能力是关键。
CREATE INDEX idx_order_filter ON orders(region, order_status, created_at DESC);通过该设计，若查询经常包含 region 和 order_status，并且需要根据 created_at 进行排序或时间范围筛选，Explain 通常显示使用了索引覆盖，避免回表，提高了查询吞吐。持续监控查询计划变化，以便在数据分布变化时及时调整。
