SQL JOIN查询应该给哪些字段建立索引-SQL-PHP中文网

必须给被驱动表的join条件字段建复合索引，单列索引无效；索引字段顺序须与on中出现顺序一致，且需覆盖所有等值关联字段，否则易退化为全表扫描。

sql join查询应该给哪些字段建立索引

必须给被驱动表的JOIN条件字段建索引，否则大概率触发全表扫描；驱动表的WHERE过滤字段、ORDER BY字段也得有索引——但顺序和组合方式错了，照样白搭。

MySQL、PostgreSQL等优化器不会合并两个单列索引去匹配 ON a.x = b.x AND a.y = b.y。哪怕你给 x 和 y 都建了单列索引，EXPLAIN 的 key_len 通常只显示一个字段长度，rows 却暴增——说明第二个条件靠全表扫描过滤。

对 INNER JOIN 或 LEFT JOIN，被驱动表（RIGHT JOIN 是左表）的全部 ON 字段必须落在**同一复合索引的最左前缀**上
索引字段顺序必须和 ON 中出现顺序一致（至少前缀匹配），例如 ON o.user_id = u.id AND o.tenant_id = u.tenant_id → users 表要建 INDEX idx_users_id_tenant (id, tenant_id)
如果 ON 写成 o.tenant_id = u.tenant_id AND o.user_id = u.id，那索引就得是 (tenant_id, id)，否则可能只用上第一个字段

驱动表没过滤好，再好的右表索引也白搭。尤其 LEFT JOIN 强制左表为驱动表，若 WHERE 条件太弱（比如只查 status = 'active' 但该字段区分度低），左表返回行数太多，右表索引就容易被跳过。

优先给高频等值过滤字段建索引，比如 WHERE created_at > '2026-04-01' 这类范围条件，不能放联合索引最左，但可放在等值字段之后
用 SHOW INDEX FROM table_name 看 Cardinality：如果远低于总行数（如100万行，Cardinality 才200），这个字段不适合当索引首列
EXPLAIN 的 Extra 出现 Using join buffer (Block Nested Loop)，就是右表已退化为全表扫描，不是数据量问题，是索引没生效

就算索引建得完全正确，只要在 ON 或 WHERE 里动了字段，就可能前功尽弃。

两表关联字段字符集不同（比如 utf8mb4 vs utf8）→ 索引无法命中，EXPLAIN 的 key 会是 NULL
ON t1.code = UPPER(t2.code) 或 WHERE DATE(created_at) = '2026-08-10' → 整个索引失效
隐式类型转换，比如 user_id 是 INT，但写成 WHERE user_id = '123'（字符串）→ 可能触发全表扫描

如果 SELECT 的字段、WHERE 条件、ORDER BY 字段都能被同一个联合索引“覆盖”，就不需要额外排序；否则数据库要回表或文件排序，性能断崖下跌。

例如 SELECT name, email FROM users WHERE status = 'active' ORDER BY created_at DESC，索引应为 (status, created_at, name, email)（覆盖索引）
如果只建了 (status, created_at)，而 name 和 email 不在索引里，MySQL 就得先用索引定位行，再回表取值，Extra 会出现 Using filesort 或 Using where; Using index 不完整
LIMIT 本身不直接要求索引，但它放大了排序和过滤效率问题——没索引时，数据库得扫完所有匹配行再截断