JOIN数量超过3个需警惕性能拐点，5表以上几乎必然拖慢查询；应限制最多JOIN 3张表，超限拆为子查询或临时表，并确保字段类型、NULL约束一致，避免隐式转换与函数调用。

JOIN数量超过3个就该警惕性能拐点

实际业务里，5表以上JOIN几乎必然拖慢查询，不是语法错，是执行计划开始崩坏。MySQL 8.0+ 的EXPLAIN FORMAT=TREE能直接看到嵌套深度，PostgreSQL 则看EXPLAIN (ANALYZE, BUFFERS)里的“Join Filter”层级——一旦出现三层以上嵌套循环（Nested Loop），基本可以判定为隐患。

• 线上查询强制限制最多JOIN 3 张表，超限必须拆成子查询或临时表
• 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没跑），优化器可能选错执行路径。生产环境定期更新统计信息比加索引还管用。