跨表统计应优先预计算和单表聚合，避免低效JOIN；推荐物化汇总表、LATERAL/子查询、先过滤后关联、EXISTS替代NULL判空。
跨表统计不一定要靠大量 JOIN，关键在提前规划数据结构和合理使用聚合策略。JOIN 多、数据量大时性能容易崩，核心思路是：能预计算的不实时算，能单表搞定的不跨表联，能用索引过滤的不全表扫。
优先用物化汇总表替代实时 JOIN
对高频访问的跨表统计（如“每个品类的月度销售额”），把 JOIN + GROUP BY 的结果定期写入一张汇总表，业务查询直接读这张表。
- 用定时任务（如每天凌晨）执行一次完整聚合，避免每次请求都 JOIN 订单表、商品表、类目表
- 汇总表字段精简，只保留统计维度（如 category_id、month、sales_amount）和必要索引
- 支持快速覆盖更新（TRUNCATE + INSERT）或增量合并（ON DUPLICATE KEY UPDATE）
用子查询或 LATERAL 替代多层 JOIN
当只需主表某几行参与统计时，JOIN 会放大中间结果集。改用相关子查询或 LATERAL（PostgreSQL）/APPLY（SQL Server），让副表计算按需触发。
- 例如查“每个用户最新一笔订单金额”，用 (SELECT amount FROM orders o2 WHERE o2.user_id = u.id ORDER BY created_at DESC LIMIT 1) 比 LEFT JOIN orders 效率高得多
- MySQL 8.0+、PostgreSQL 支持 LATERAL，可让子查询引用外层表字段，逻辑清晰且优化器更易下推条件
拆分 JOIN：先过滤再关联
大表 JOIN 前没过滤，是性能杀手。务必把 WHERE 条件尽量下沉到被 JOIN 的表上，或提前用 CTE/临时表裁剪数据。
- 错误写法：SELECT * FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' —— 先全量 JOIN 再过滤
- 正确写法：先用 CTE 提取活跃用户 ID，再与 orders 关联；或确保 orders 表有 user_id + status 的联合索引，并在 JOIN 条件中带上状态约束
- 对超大订单表，可加时间分区（如按 month 分区），让优化器自动跳过无关分区
用 EXISTS / IN 替代 LEFT JOIN … IS NULL 判空
检查“有无关联记录”这类逻辑，JOIN 配合 NULL 判断不仅写法绕，还容易引发全表扫描。
- 查“没有下单的用户”，用 SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)
- EXISTS 只关心是否存在，找到即停；而 LEFT JOIN 需生成全部关联结果再判 NULL，内存和 CPU 开销都更大
- 注意：IN 子句若右侧含 NULL，结果可能意外为空，优先选 EXISTS
基本上就这些。不是所有 JOIN 都该消灭，而是把 JOIN 留给真正需要关联语义的地方——比如要同时返回用户信息和订单明细。其他场景，预计算、子查询、精准过滤，往往更稳更快。
