JOIN数量超过3个需警惕性能拐点，5表以上几乎必然拖慢查询；应限制最多JOIN 3张表，超限拆为子查询或临时表，并确保字段类型、NULL约束一致，避免隐式转换与函数调用。
JOIN数量超过3个就该警惕性能拐点
实际业务里，5表以上JOIN几乎必然拖慢查询，不是语法错，是执行计划开始崩坏。MySQL 8.0+ 的EXPLAIN FORMAT=TREE能直接看到嵌套深度，PostgreSQL 则看EXPLAIN (ANALYZE, BUFFERS)里的“Join Filter”层级——一旦出现三层以上嵌套循环（Nested Loop），基本可以判定为隐患。
- 线上查询强制限制最多
JOIN3 张表，超限必须拆成子查询或临时表 -
LEFT JOIN比INNER JOIN更易引发全表扫描，尤其右表无索引时，务必检查EXPLAIN中type是否为ALL或index - 用
STRAIGHT_JOIN（MySQL）或/*+ Leading() */（PostgreSQL）手动指定连接顺序，避免优化器误判
连接字段必须严格匹配数据类型和NULL约束
常见错误是user.id（BIGINT）去JOIN order.user_id（VARCHAR），表面能跑通，但会触发隐式类型转换，导致索引失效。更隐蔽的是NOT NULL字段和允许NULL的字段混用——即使值全非空，优化器也可能放弃使用索引。
- 确认两边字段类型完全一致：
DESCRIBE table_name或\d table_name查data_type和is_nullable - 字符串字段JOIN前加
TRIM()或CAST(... AS CHAR)看似稳妥，实则破坏索引，应提前清洗入库 - 时间字段慎用
DATE(created_at)作为连接条件，会绕过created_at上的索引，改用范围查询替代
ON条件里别塞WHERE逻辑
LEFT JOIN后在WHERE里写right_table.status = 'active'，等价于把LEFT JOIN降级为INNER JOIN，丢失左表无匹配记录的行。这是线上漏数据的高频原因。
- 过滤右表必须写进
ON子句：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'active' - 若需保留左表全量且对右表做复杂过滤，先用子查询或CTE预过滤右表，再JOIN
-
ON中避免函数调用（如ON UPPER(a.name) = UPPER(b.name)），除非该字段上建了函数索引
小表驱动大表不是玄学，得看rows和filtered
所谓“小表驱动”，本质是让EXPLAIN中rows最小的表当驱动表。filtered值低（比如10%）说明条件过滤性差，即使表小也不适合作为驱动——它会导致大量无效匹配传给下一层。
- 用
SELECT COUNT(*)快速估算各表有效参与JOIN的行数，而非总行数 - 对高基数字段（如
user_id）建索引比对低基数字段（如status）更有效，尤其当filtered> 90%时 - 复合索引顺序必须匹配
ON中的字段顺序，例如ON a.x = b.x AND a.y = b.y，则索引应为(x, y)而非(y, x)
最常被忽略的一点：JOIN字段上有索引，不代表执行时一定用得上——如果统计信息过期（ANALYZE TABLE没跑），优化器可能选错执行路径。生产环境定期更新统计信息比加索引还管用。
