SQL跨表统计需正确使用JOIN与聚合函数，明确一对多或多对多关系以选择合适JOIN类型和聚合位置，优先子查询/CTE预聚合、条件过滤下推、建立匹配索引，并用EXPLAIN验证执行计划。
SQL跨表统计的核心是用好JOIN和聚合函数（如COUNT、SUM、AVG），同时避免笛卡尔积、重复计算和全表扫描。写得对，性能差不了；写错一点，数据不准还跑得慢。
明确关联关系再写JOIN
跨表统计前，先确认主表和从表的逻辑关系：是一对一、一对多，还是多对多？这直接影响JOIN类型和聚合位置。
- 一对多（如订单表 ← 订单明细表）：通常以主表为基准，
LEFT JOIN后在主表维度聚合，避免明细行导致主表记录被“撑大” - 多对多（如学生表 ↔ 课程表，中间有选课表）：必须通过中间表连接，且聚合一般放在最终结果层，不在中间表上提前
GROUP BY - 不确定是否有匹配记录？优先用
LEFT JOIN+COALESCE(字段, 0)，别依赖INNER JOIN过滤掉空值
聚合尽量靠近数据源头
别等所有表连完再算总数——能先在子表里汇总，就别拖到最外层。减少中间结果集大小，是提速关键。
- 错误示范：
FROM orders o JOIN order_items i ON o.id = i.order_id GROUP BY o.user_id→ 若一个用户有上千条明细，JOIN后生成大量重复用户行才聚合 - 推荐写法：先用子查询或CTE对
order_items按order_id汇总金额/数量，再与orders关联，最后按user_id统合 - MySQL 8.0+/PostgreSQL支持
LATERAL JOIN，适合“每行主表关联其动态聚合子表”的场景
善用条件过滤下推
WHERE条件别全堆在最后。把能缩小数据量的过滤（尤其是时间范围、状态码、ID列表）尽量写在对应表的ON或子查询里。
- 例如统计“近30天已支付订单的客户复购率”，应先把
orders用WHERE status = 'paid' AND create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)筛一遍，再JOIN用户表 - JOIN时用
ON t1.id = t2.t1_id AND t2.status = 'valid'，比写成ON ... WHERE t2.status = 'valid'更早切断无效关联 - 注意：外连接中，对右表的过滤若写在
WHERE会转成内连接效果，务必检查逻辑是否符合预期
索引不是加了就快，要配对JOIN和WHERE字段
跨表统计慢，八成是因为缺索引。但索引要建在真正参与连接和过滤的列上，且注意组合索引顺序。
- JOIN字段必须有索引：比如
orders.user_id和users.id都要有索引，否则驱动表扫一次，被驱动表就得全表匹配 - 高频过滤+JOIN组合列建议建联合索引：如常按
status和create_time查订单，又用user_id关联，则(status, create_time, user_id)可能比单列索引更高效 - 用
EXPLAIN看执行计划：重点关注type是否为ref/range（好），避免ALL（全表扫描）和index（索引全扫）
基本上就这些。跨表统计不复杂，但容易忽略关联逻辑和执行路径。写之前想清楚“我要按谁分组”“哪些行该被保留”“哪张表最先筛”，再动手敲代码，准确性和效率自然就上来了。
