JOIN条件字段必须建复合索引，单列索引无效；主流数据库不支持自动合并单列索引匹配多条件JOIN，须为每张表按ON字段顺序（等值优先、高选择性在左）创建对应复合索引，并确保LEFT JOIN右表索引被驱动表过滤强度支撑。
JOIN条件字段必须建复合索引，单列索引无效
MySQL、SQL Server、PostgreSQL 等主流数据库优化器不会自动合并两个单列索引去匹配 ON a.x = b.x AND a.y = b.y 这类多条件 JOIN。哪怕你给 x 和 y 都单独建了索引，EXPLAIN 中的 key_len 通常只显示一个字段长度，rows 却暴增——说明第二个条件实际靠全表扫描过滤。
必须为每张参与 JOIN 的表分别建复合索引，且字段顺序要严格匹配 ON 中出现的顺序（至少前缀一致）：
-
ON o.user_id = u.id AND o.tenant_id = u.tenant_id→orders表建INDEX idx_orders_user_tenant (user_id, 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, user_id)，否则可能只用上第一个字段
字段顺序不能按“主键习惯”排，得看选择性和查询模式
很多人一上来就写 (user_id, tenant_id)，觉得 user_id 更“核心”，但效果可能很差。真正该放最左的，是那个在 WHERE 或 ON 中更常作为等值条件、且区分度更高的字段。
- 高选择性字段优先：比如
user_id是百万级唯一值，tenant_id只有几十个取值 →user_id更适合作首列 -
WHERE中高频等值字段优先：多数查询都带WHERE tenant_id = ?→ 就该把tenant_id放最左 - 低区分度字段（如
status、is_deleted）别放最左：SHOW INDEX FROM table_name看Cardinality，如果远低于总行数（比如 100 万行，Cardinality才 200），这个字段就不适合当首列
LEFT JOIN 下右表索引更容易被忽略
INNER JOIN 下优化器还能尝试索引合并，但 LEFT JOIN 强制左表为驱动表，右表索引是否生效更依赖左表返回行数是否足够小。哪怕你建了完美匹配的复合索引，只要驱动表没过滤好，右表索引也可能被跳过。
- 左表必须有强
WHERE条件（如WHERE created_at > '2026-04-01'），让rows显著下降 - 右表的
ON字段必须全部落在同一复合索引的最左前缀上，不能分散在多个索引里 - 盯紧
EXPLAIN的Extra列：出现Using join buffer (Block Nested Loop)就说明右表已退化为全表扫描，不是数据量问题，是索引没被识别或没生效 - 严禁在右表
ON条件中用函数，比如ON t1.code = UPPER(t2.code)→ 整个索引失效
SQL Server 索引视图对聚合 JOIN 场景的特殊要求
如果 JOIN 后还要做 SUM、COUNT 等聚合，且想固化结果加速查询，SQL Server 的索引视图是可行路径，但它有一套硬性校验规则，缺一不可：
-
CREATE VIEW必须显式包含WITH SCHEMABINDING，否则提示Cannot create index on view because the view is not schema bound - 聚合必须用
COUNT_BIG(*)，不能用COUNT(*)；SUM()、AVG()等需确保操作列非空或已处理null -
GROUP BY必须覆盖所有参与 JOIN 的关键列，且基表对应列要有唯一约束（主键或唯一非空索引） - 所有表名、列名必须两段式（如
dbo.Sales.ProductID），不能省略schema - 查询时必须显式引用视图并加
WITH (NOEXPAND)，否则 Standard / Express 版本根本不会用它
真正难的不是写 SQL，而是让每个字段都满足约束条件——比如 ProductID 在基表上必须有主键或唯一非空索引，否则 CREATE UNIQUE CLUSTERED INDEX 一定失败，而且错误信息不直接告诉你缺的是这个。
