在文章系统中怎样通过MySQL联合索引优化多条件组合查询-mysql教程-PHP中文网

联合索引必须满足最左前缀匹配，否则无法生效；B+树按索引列顺序整体排序，缺最左列则无法定位起点；列序影响命中率、排序复用及过滤效率，须结合选择性、等值/范围查询类型合理设计，并以EXPLAIN验证。

在文章系统中怎样通过mysql联合索引优化多条件组合查询

联合索引不是“有列就用”，而是必须满足最左前缀匹配

很多开发者以为只要 WHERE 里出现了联合索引中的某几列，MySQL 就会走索引——这是最常见的误判。实际上，KEY idx_name_age_status (name, age, status) 这个索引，只有以下情况能生效：

WHERE name = 'Alice' → 走 name 列
WHERE name = 'Alice' AND age = 25 → 走 name, age
WHERE name = 'Alice' AND age = 25 AND status = 'active' → 全部三列都走
WHERE name = 'Alice' AND status = 'active' → 仅 name 有效，status 不会跳过 age 单独使用
WHERE age = 25 AND status = 'active' → 索引完全失效（缺最左列 name）

根本原因是 B+ 树按 (name, age, status) 整体排序，没 name 就无法定位搜索起点。优化器不会“智能补全”，也不会重排条件顺序来适配索引。

多条件查询场景下，列顺序决定索引是否真正可用

联合索引的列序不是随便排的，它直接影响哪些查询能命中、哪些被强制回表或全表扫描。例如文章系统常见查询：

SELECT * FROM articles WHERE status = 'publish' AND category_id = 5 AND created_at > '2026-01-01'
如果建索引为 KEY idx_status_cat_time (status, category_id, created_at)，这个查询能用上全部三列
但如果建反了，比如 KEY idx_cat_status_time (category_id, status, created_at)，那上面查询只用到 category_id，后两列全部失效
更糟的是：如果 status 只有 2–3 个取值（如 draft/publish/deleted），选择性极低，放前面反而降低过滤效率

优先把高选择性列（如 category_id、author_id）放最左；等值查询列（=）放前面，范围查询列（>、BETWEEN）靠后——因为范围列之后的字段自动失效。

ORDER BY 和 GROUP BY 能否复用联合索引，取决于字段顺序和方向一致性

文章列表页常带排序，比如 ORDER BY category_id, created_at DESC。这时候联合索引能不能省掉 filesort，关键看定义是否严格匹配：

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

KEY idx_cat_time (category_id, created_at) → ORDER BY category_id, created_at DESC 在 MySQL 8.0+ 可用（支持混合方向）
KEY idx_cat_time (category_id, created_at) → ORDER BY category_id DESC, created_at ASC 在 MySQL 5.7 中会直接放弃索引排序
KEY idx_time_cat (created_at, category_id) → ORDER BY category_id, created_at 完全不匹配最左前缀，必然 filesort
注意：WHERE 和 ORDER BY 的字段必须共享同一个最左前缀，否则优化器不会合并使用

一个典型坑是：加了 WHERE status = 'publish'，但索引是 (created_at, category_id)，此时 ORDER BY created_at 虽然能用索引，但 WHERE 条件根本走不上——优化器大概率选全表扫描或临时索引合并，而非你预想的路径。

EXPLAIN 是唯一可信依据，别信“应该能走索引”这种猜测

即使 SQL 看起来完全符合最左前缀，也必须用 EXPLAIN 验证。重点看三列：

key 字段是否显示你期望的联合索引名
key_len 是否符合预期（比如 idx_a_b_c 上 WHERE a = ? AND b = ?，key_len 应该是 a+b 的字节数，不是只算 a）
Extra 是否出现 Using filesort 或 Using temporary —— 出现就说明排序/分组没复用索引