MySQL联合索引字段顺序如何确定-mysql教程-PHP中文网

高频必查的等值字段（如tenant_id、user_id）必须放最左，因b+树查找需从最左列开始连续匹配；跳过则索引失效，范围字段须置右以防阻断后续列使用，order by/group by字段需紧接等值条件且顺序方向一致。

mysql联合索引字段顺序如何确定

WHERE 条件里哪些字段必须放最左

联合索引生效的前提是 WHERE 必须包含最左列，且后续列要连续出现。比如索引 (tenant_id, user_id, status)，只有 WHERE tenant_id = ?、WHERE tenant_id = ? AND user_id = ? 或 WHERE tenant_id = ? AND user_id = ? AND status = ? 才能完整走索引；WHERE user_id = ? 或 WHERE status = ? 直接失效。

高频、必查的等值字段（如 tenant_id、user_id）必须放最左——不是因为“它在 SQL 里写得靠前”，而是因为它决定了 B+ 树的查找起点。跳过它，MySQL 就找不到入口。

区分度低的字段（如 is_deleted、gender）别放最左，否则树第一层节点太多，实际过滤效率差
哪怕 email 区分度更高，只要它不总出现在 WHERE 开头（比如只在 20% 查询里出现），就不该抢第一位
用 SHOW INDEX FROM table_name 查看 Cardinality，粗估字段区分度：COUNT(DISTINCT col) / COUNT(*)

范围查询字段为什么不能放最左或中间断开

>、、<code>BETWEEN、LIKE 'abc%' 这类操作会让索引“停在这一列”。例如索引 (a, b, c) 配合 WHERE a = 1 AND b > 10 AND c = 5，MySQL 只能用上 a 和 b 做查找，c = 5 不参与索引查找（可能用于排序或覆盖，但不会缩小扫描范围）。

更危险的是：如果把范围字段放最左，比如 (created_at, status)，而查询常是 WHERE created_at > '2025-01-01'，那整个索引基本白建——优化器大概率直接走全表扫描。

范围字段应放在等值字段之后，且尽量靠右
若必须支持 WHERE status = ? AND created_at > ?，优先保证 status 在左，再补高区分度前缀（如加 tenant_id 到最左）
LIKE '%abc' 或 LIKE '%abc%' 会让整个索引前缀失效，别指望它走索引

ORDER BY 和 GROUP BY 字段怎么塞进联合索引

排序和分组字段要“紧接在等值条件之后”，且顺序、方向必须严格一致。比如索引 (a, b, c) 支持 WHERE a = 1 ORDER BY b, c，但不支持 WHERE a = 1 ORDER BY c，也不支持 ORDER BY b DESC, c ASC（方向不一致）。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

如果查询是 SELECT * FROM t WHERE a = 1 ORDER BY b，而索引是 (a, c, b)，中间插了 c，那 ORDER BY b 就触发 Using filesort——B+ 树里 b 并不连续有序。

GROUP BY a, b 要加速，索引必须是 (a, b) 或 (a, b, c)，不能是 (a, c, b)
写 SQL 时条件顺序不影响是否走索引（优化器会重排），但索引定义顺序决定能否支撑排序
EXPLAIN 看 Extra 字段：出现 Using filesort 就说明排序没走索引

覆盖索引要不要把 SELECT 字段全加进去

如果查询经常是 SELECT id, name, status FROM t WHERE status = ? ORDER BY create_time，建索引 (status, create_time, id, name) 可以避免回表——查完索引树就拿到全部数据，Extra 显示 Using index。

但要注意：主键自动包含在二级索引中，所以 (status, create_time) 实际已含主键 id，无需重复加 id；而 name 是非主键字段，要覆盖就得显式加上。