跨表统计可以说是SQL日常开发中最常见、也最容易写出问题的场景。单表统计通常只需要 GROUP BY 和聚合函数，但一旦涉及两个甚至更多表，统计结果是否准确就取决于关联键、关联类型、过滤条件的位置以及聚合粒度。本文不准备罗列所有语法，而是通过一个真实业务统计案例，把跨表统计的完整思路拆开，帮你建立可复用的复杂查询分析方法。
从需求开始：先确定统计口径再写 SQL
假设现在有两张表：用户表 users 和订单表 orders。users 表保存用户信息，orders 表保存用户下的订单。需求是统计每个用户的累计消费金额、订单数量以及最近一次下单时间。这个需求看起来简单，但在实际写之前，必须明确几个口径：用户是否包含没有下过单的人？订单状态是否需要过滤？金额字段是否包含退款？如果这些口径不明确，写出来的 SQL 很可能在测试环境看起来正常，上线后却出现数据不一致。
以是否包含没有订单的用户为例，如果只统计有订单的用户，使用 INNER JOIN 是合适的；如果希望所有用户都出现在结果中，没有订单的用户消费金额显示为 0，就必须使用 LEFT JOIN。很多错误并不是语法错误，而是这一步判断错了。比如下面这个写法，如果业务要求全量用户，它就会漏掉没有任何订单的用户。
SELECT u.user_id,
u.user_name,
SUM(o.order_amount) AS total_amount,
COUNT(o.order_id) AS order_count,
MAX(o.created_at) AS last_order_time
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id
GROUP BY u.user_id, u.user_name;
上面的 SQL 在 orders 表中没有匹配记录的用户不会出现在结果里。原因在于 INNER JOIN 只保留两表都存在的关联键。还有一种隐性问题：如果 orders 表中同一个用户有多个订单，COUNT(o.order_id) 没问题，但如果统计用户数量时写成 COUNT(u.user_id)，在 JOIN 之后行数已经被订单行撑开，结果就会偏大。这是跨表统计中最典型的重复计数问题。
JOIN 类型与聚合粒度：先关联还是先聚合
搞清楚 JOIN 类型后，下一个关键点是聚合粒度。跨表统计中经常出现两张表是一对多关系，此时如果先 JOIN 再聚合，虽然能拿到明细，但会带来不必要的行膨胀；如果先聚合再 JOIN，则能减少中间结果，提升查询效率。比如上面的需求，如果只关心每个用户的订单汇总，不关心订单明细，完全可以先在 orders 表内聚合，再与 users 表关联。
SELECT u.user_id,
u.user_name,
COALESCE(o.total_amount, 0) AS total_amount,
COALESCE(o.order_count, 0) AS order_count,
o.last_order_time
FROM users u
LEFT JOIN (
SELECT user_id,
SUM(order_amount) AS total_amount,
COUNT(order_id) AS order_count,
MAX(created_at) AS last_order_time
FROM orders
GROUP BY user_id
) o ON u.user_id = o.user_id;
这个写法的好处是子查询先把 orders 压缩成每个用户一行，再和 users 做 LEFT JOIN。对于 users 表很大、orders 表也很大的情况，中间结果会小很多。当然，这也不是绝对最优，如果 orders 表上有 user_id 索引且过滤条件能快速定位少量订单，先 JOIN 再聚合可能更直接。判断方式应该结合实际执行计划，看是排序聚合成本高，还是 JOIN 的行数膨胀成本高。
另一个容易混淆的是窗口函数与 GROUP BY 的区别。窗口函数不会合并行，它可以在保留明细的同时附加统计值；GROUP BY 则会把相同分组的行压缩。如果在跨表统计中需要明细和汇总同时出现，窗口函数往往比多次 JOIN 更清晰。例如要统计每个用户每笔订单金额占该用户总消费金额的比例，可以先 JOIN 出明细，再使用 SUM 窗口函数。
SELECT u.user_id,
u.user_name,
o.order_id,
o.order_amount,
SUM(o.order_amount) OVER (PARTITION BY u.user_id) AS user_total_amount,
ROUND(o.order_amount * 100.0 / SUM(o.order_amount) OVER (PARTITION BY u.user_id), 2) AS amount_percent
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
这种查询在报表和数据分析中很常见。它避免了在 SELECT 中反复写子查询，也让同一分组下的汇总逻辑更容易维护。但要注意窗口函数是在 WHERE 之后、ORDER BY 之前计算的，如果口径中还涉及过滤，应该先想清楚过滤条件是否应该影响窗口计算。
多表关联与复杂口径：用 EXISTS 和条件聚合拆解
真实业务往往不只两张表。比如还要统计每个用户购买过的商品品类数、使用优惠券的订单数等。此时如果继续无脑 JOIN 多张表，行数会以乘法方式膨胀，统计结果极易出错。对于“是否存在”类口径，优先考虑 EXISTS 或 IN 子查询；对于“满足某个条件的数量”类口径，优先考虑条件聚合，也就是在 SUM 或 COUNT 内部使用 CASE WHEN。
例如用户表 users、订单表 orders、订单商品表 order_items、商品表 products，要统计每个用户的总订单数、购买过的品类数以及使用优惠券的订单数。直接 JOIN 这四张表后，一个订单下多个商品会导致订单金额和订单数重复计算。更稳妥的做法是把订单级统计和商品级统计分开，再按用户聚合。
SELECT u.user_id,
u.user_name,
COALESCE(o.order_count, 0) AS order_count,
COALESCE(o.coupon_order_count, 0) AS coupon_order_count,
COALESCE(oi.category_count, 0) AS category_count
FROM users u
LEFT JOIN (
SELECT user_id,
COUNT(order_id) AS order_count,
SUM(CASE WHEN coupon_id IS NOT NULL THEN 1 ELSE 0 END) AS coupon_order_count
FROM orders
GROUP BY user_id
) o ON u.user_id = o.user_id
LEFT JOIN (
SELECT o.user_id,
COUNT(DISTINCT p.category_id) AS category_count
FROM orders o
INNER JOIN order_items oi ON o.order_id = oi.order_id
INNER JOIN products p ON oi.product_id = p.product_id
GROUP BY o.user_id
) oi ON u.user_id = oi.user_id;
上面的 SQL 中，订单级统计在一个子查询内完成，商品级品类数在另一个子查询内完成，最后统一 LEFT JOIN 到用户表。这样每个子查询内部都是单一粒度，避免了跨粒度重复计数。COUNT(DISTINCT p.category_id) 用来统计用户购买过的不同品类数，如果只是 COUNT(p.category_id)，同一品类下多个商品会被重复计入。
条件聚合在复杂口径中非常有用。它把原本需要 WHERE 过滤后多次查询的逻辑合并到一条 SQL 中，同时保证所有分组都能保留。比如要统计每个用户成功订单数、失败订单数、退款订单数，可以写：
SELECT user_id,
COUNT(order_id) AS total_orders,
SUM(CASE WHEN status = 'success' THEN 1 ELSE 0 END) AS success_orders,
SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failed_orders,
SUM(CASE WHEN status = 'refunded' THEN 1 ELSE 0 END) AS refunded_orders
FROM orders
GROUP BY user_id;
这种写法比分别写三条带 WHERE 的查询再合并结果要高效得多，而且逻辑集中，后续维护时不容易遗漏某个状态。
性能优化：索引、执行计划与临时表的取舍
跨表统计查询往往涉及大数据量，写完正确 SQL 只是第一步，接下来要考虑性能。首先要关注关联字段的索引。JOIN 条件中的字段如果没有索引，数据库可能选择全表扫描或哈希连接，数据量大时性能会明显下降。以 orders.user_id 为例，如果经常按用户统计订单，应在 orders 表的 user_id 字段上建立索引。对于组合条件，如 WHERE status = 'success' AND user_id = 123，可以考虑建立 (user_id, status) 的复合索引。
其次要养成查看执行计划的习惯。不同数据库执行计划的语法不同，但核心思路一致：关注扫描类型、行数估计、连接算法以及是否有排序或临时表操作。如果发现执行计划中某个子查询产生了巨大的中间结果，可以尝试调整子查询的过滤条件，或者将子查询物化为临时表，再与主表连接。例如 MySQL 中可以使用 CREATE TEMPORARY TABLE，也可以使用 WITH 子句生成公共表表达式，提高可读性和复用性。
WITH user_order_stats AS (
SELECT user_id,
SUM(order_amount) AS total_amount,
COUNT(order_id) AS order_count
FROM orders
WHERE created_at >= '2025-01-01'
GROUP BY user_id
)
SELECT u.user_id,
u.user_name,
COALESCE(s.total_amount, 0) AS total_amount,
COALESCE(s.order_count, 0) AS order_count
FROM users u
LEFT JOIN user_order_stats s ON u.user_id = s.user_id;
这个例子中，WITH 子查询先把一段时间内的订单统计出来，再与用户表关联。这样做的好处是逻辑清晰，同时数据库优化器可能选择更优的连接顺序。需要注意的是，不是所有数据库都会自动物化 CTE，有些数据库会将其内联展开，所以仍然需要结合实际执行计划判断。
还有一个容易被忽视的优化点是避免在 JOIN 条件或 WHERE 条件中对字段使用函数。比如 WHERE DATE(created_at) = '2025-01-01' 会导致索引失效，因为函数作用于字段后，数据库无法直接利用索引范围扫描。应尽量改为 created_at >= '2025-01-01 00:00:00' AND created_at < '2025-01-02 00:00:00'。这类细节在跨表统计查询中会显著影响扫描行数。
总结一下，SQL 跨表统计并不只是记住 JOIN 语法，而是一个从口径确认、粒度拆分到性能验证的完整过程。遇到复杂需求时，先用文字描述每个统计指标的粒度，再决定哪些子查询先聚合、哪些用 LEFT JOIN 保留全量、哪些用 EXISTS 判断存在性，最后通过索引和执行计划做优化。按照这个顺序写出来的 SQL，准确性和可维护性都会更好。