跨表统计需先理清业务逻辑和数据关系，明确主表、统计维度、关联字段唯一性及空值处理；避免多对多重复计算，善用子查询聚合或EXISTS/IN；注意NULL兜底与性能优化。
跨表统计不是简单拼几个表，关键在理清业务逻辑和数据关系。先确定要算什么、从哪几张表取数、关联字段是否唯一、空值怎么处理——这些想清楚了，SQL自然就顺了。
明确主表和统计维度
别一上来就 JOIN 所有表。先问自己：最终结果按什么分组？比如“每个部门的订单总金额”，那 部门表是主表，订单表是明细表。如果漏掉部门没订单的情况，就得用 LEFT JOIN；如果只看有订单的部门，INNER JOIN 更安全。
- 主表决定结果行数（如部门有5个，结果最多5行）
- 统计字段（如金额、数量）通常来自从表，记得加 SUM()、COUNT() 等聚合函数
- WHERE 条件尽量写在关联后、GROUP BY 前，避免过滤掉不该过滤的主表记录
小心多对多导致的重复计算
订单表 × 订单商品表 × 商品分类表，很容易因一对多叠加变成多对多，SUM(amount) 被放大好几倍。真实案例：某次统计各分类销售额，结果翻了3倍——查出来是同一笔订单含多个商品，又跨了多个分类标签。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 先用 COUNT(*) 和 COUNT(DISTINCT order_id) 对比，发现差异就说明有重复
- 解决办法：要么在子查询里先聚合（如先按 order_id 汇总金额），再关联分类；要么用 EXISTS/IN 替代 JOIN 做条件判断
- 临时加个 ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY id) 辅助排查也很管用
空值和NULL要主动兜底
LEFT JOIN 后，从表字段可能为 NULL。SUM(NULL) 是 NULL，COUNT(字段) 会忽略 NULL，但 COUNT(*) 不会——这些细节不注意，统计结果就“少了一块”。
- 金额类字段统一用 COALESCE(amount, 0) 再聚合
- 计数类字段若需包含无记录情况，写 COUNT(1) 或 COUNT(*)，别写 COUNT(从表.id)
- 分组字段本身为空？加一句 WHERE dept_name IS NOT NULL 避免脏数据干扰
性能不卡的关键：小表驱动 + 条件下推
100万订单表 JOIN 1万商品表，和反过来，执行计划可能差10倍。看执行计划（EXPLAIN）时重点盯两点：驱动表是不是小的、JOIN 条件有没有走索引。
- 把带 WHERE 过滤的表放前面（如只统计2024年订单，就把订单表放 LEFT JOIN 左侧）
- ON 条件字段必须建索引，尤其是被 JOIN 的从表外键字段
- 大表聚合别放最后，先用子查询或 CTE 把中间结果压到千行级再 JOIN
基本上就这些。跨表统计不复杂但容易忽略边界，动手前多画个ER草图，跑之前先 LIMIT 10 看数据对不对——省下的调试时间，够写三段SQL了。
