join顺序影响执行计划与性能，应将过滤后结果集最小的表作驱动表，避免on中使用函数导致索引失效，改用范围条件。

JOIN顺序直接影响执行计划和性能

数据库优化器不是万能的，尤其在多表关联时，JOIN 的书写顺序常被当作物理执行顺序处理。MySQL 5.7 及更早版本、SQL Server 默认都按 FROM 后的表顺序驱动；PostgreSQL 虽有代价估算，但小样本统计信息下也容易选错驱动表。

• 把过滤条件最严、结果集最小的表放在 FROM 后第一位（即驱动表），例如用户表 users 有千万级，但加了 WHERE status = 'active' 后只剩 2 万，就该让它当驱动表
• 避免在 ON 条件里写函数，比如 ON DATE(created_at) = DATE(other_date) 会失效索引；改用范围条件：ON created_at >= other_date::date AND created_at
• 对大表 JOIN，优先考虑走索引字段关联；若关联字段无索引，即使加了 WHERE 也大概率触发全表扫描

LEFT JOIN + WHERE 子句可能悄悄变成 INNER JOIN

这是最隐蔽也最常踩的坑：一旦在 LEFT JOIN 后的 WHERE 中对右表字段加非空判断，优化器就会剔除所有右表为 NULL 的行——等价于强制转成 INNER JOIN。

• 错误写法：SELECT * FROM orders o LEFT JOIN customers c ON o.cid = c.id WHERE c.country = 'CN' → 实际丢掉所有无客户信息的订单
• 正确写法：把右表过滤条件移到 ON 子句：LEFT JOIN customers c ON o.cid = c.id AND c.country = 'CN'
• 若必须保留左表全部记录且只统计某类右表数据，用条件聚合更安全：COUNT(CASE WHEN c.country = 'CN' THEN 1 END)

GROUP BY 多维统计时别漏掉非聚合字段

在标准 SQL（如 PostgreSQL、SQL Server）中，SELECT 列表里所有非聚合字段都必须出现在 GROUP BY 中；MySQL 5.7+ 严格模式下同理。否则要么报错 ERROR 1055，要么返回不可靠的“随机值”。

• 比如要按城市+会员等级统计订单数和平均金额：SELECT city, level, COUNT(*), AVG(amount) FROM users u JOIN orders o ON u.id = o.uid GROUP BY city, level
• 如果只写 GROUP BY city 却 SELECT level，MySQL 旧版本可能返回某个 level 值，但不保证是最高/最低/最常见的那个
• 跨数据库移植时尤其注意：SQLite 允许，但 PostgreSQL 会直接拒绝，别依赖 MySQL 的宽松行为

用 EXISTS 替代 JOIN 做存在性判断更轻量

当目标只是“查出所有有订单的用户”，而不是要拿订单字段做计算，用 EXISTS 比 JOIN 更高效——它找到第一条匹配就停，不构造中间结果集。

• 低效：SELECT DISTINCT u.* FROM users u JOIN orders o ON u.id = o.uid → 先 JOIN 出所有用户-订单组合，再去重
• 高效：SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.uid = u.id) → 对每个用户只确认是否存在订单，不读取订单内容
• 注意子查询里别漏 WHERE 关联条件，否则变成全表扫描；也别写 SELECT *，用 SELECT 1 即可

多表交叉分析真正的复杂点不在语法，而在你是否清楚每张表的数据分布、索引覆盖情况，以及执行计划里实际走了哪条路径。光靠 EXPLAIN 看不出隐式类型转换或统计信息过期带来的偏差，得结合 ANALYZE TABLE 和真实数据量验证。