复合索引遵循最左前缀原则，需按查询条件顺序设计，等值列在前、范围列在后，如(status, created_time)可高效支持WHERE status=1 AND created_time>'2024-01-01'。
在MySQL中，复合索引（也叫联合索引）是提升复杂查询性能的关键手段。当你频繁根据多个字段进行查询、排序或过滤时，合理使用复合索引可以显著减少扫描行数，提高执行效率。
理解复合索引的结构
复合索引是基于多个列创建的B+树索引，数据按索引列的顺序排序。例如：
CREATE INDEX idx_name ON table (col1, col2, col3);这个索引会先按 col1 排序，再按 col2，最后按 col3。这意味着索引遵循“最左前缀”原则——只有从最左边开始的连续列才能被有效利用。
比如以下查询能命中该索引：
- WHERE col1 = 'a'
- WHERE col1 = 'a' AND col2 = 'b'
- WHERE col1 = 'a' AND col2 = 'b' AND col3 = 'c'
但下面这些通常无法充分利用索引：
- WHERE col2 = 'b'（跳过了col1）
- WHERE col2 = 'b' AND col3 = 'c'（未包含最左列）
为复杂查询设计合适的复合索引
要让复合索引真正起作用，必须结合实际查询语句来设计。考虑以下几点：
- 等值条件放前面：把 WHERE 中使用 = 的列放在索引左侧。例如 WHERE status = 1 AND created_time > '2024-01-01'，应建索引 (status, created_time)。
- 范围查询放后面：范围操作（>,
- 覆盖索引减少回表：如果索引包含了查询所需的所有字段，MySQL就不需要回到主表取数据，称为“覆盖索引”。例如查询 SELECT id, user_id FROM orders WHERE status = 1 ORDER BY create_time，可建立 (status, create_time, user_id) 索引，尽量避免回表。
结合排序和分组优化
ORDER BY 和 GROUP BY 操作若能直接利用索引顺序，可避免额外的排序（filesort）或临时表。
例如：
SELECT * FROM logs WHERE app_id = 100 ORDER BY timestamp DESC LIMIT 10;这时建立 (app_id, timestamp) 索引，就能同时满足过滤和排序需求，执行计划中不会出现 filesort。
注意方向一致性：如果排序是 DESC，而索引默认是升序，某些情况下仍需排序。可在支持的存储引擎（如InnoDB）中通过优化器处理，但最好保持一致。
避免常见误区
- 不要盲目添加索引：每个索引都会增加写入开销，并占用磁盘空间。只针对高频、慢查询创建复合索引。
- 列顺序很重要：错误的列序可能导致索引失效。分析查询中最严格的过滤条件优先。
- 区分度高的列靠前：比如性别只有两个值，不适合放复合索引第一位，除非组合后整体区分度高。
- 定期检查索引使用情况：通过 SHOW INDEX FROM table 和 information_schema.statistics 查看，也可以用 EXPLAIN 分析SQL是否命中预期索引。
基本上就这些。关键是理解你的查询模式，按最左匹配、等值在前、范围在后、覆盖优先的原则设计复合索引，就能有效加速复杂查询。
