应根据业务逻辑选择JOIN类型：需保留无明细订单时用LEFT JOIN，仅处理有明细订单时用INNER JOIN；GROUP BY必须包含所有非聚合字段；注意NULL处理及JOIN导致的笛卡尔放大；JOIN和聚合字段需建索引。
JOIN 用 INNER 还是 LEFT？先看业务逻辑要什么
订单汇总时最常踩的坑，就是一上来就写 INNER JOIN，结果漏掉没明细的订单（比如只有订单头、还没录入商品）。如果目标是“所有订单 + 它们的明细合计”，必须用 LEFT JOIN：主表是订单表，明细表在右边，即使某订单没有明细行，也能保留该订单记录，聚合字段（如总金额、商品数）会是 NULL 或可被 COALESCE 处理。
反过来，如果只关心“有明细的订单”，或者要做明细级计算（比如每条明细打标），INNER JOIN 更安全，避免空值干扰后续逻辑。
GROUP BY 必须包含订单主键，不能只写 SELECT 列
汇总意味着对明细行做聚合（SUM、COUNT 等），SQL 要求所有非聚合字段都得出现在 GROUP BY 中。常见错误是只写 GROUP BY order_id，但 SELECT 里又选了 order_date、customer_name 等——这些字段必须一起进 GROUP BY，否则多数数据库（如 PostgreSQL、SQL Server）直接报错：column "xxx" must appear in the GROUP BY clause。
实操建议：
- 把订单表所有需展示的非聚合字段，全部列进
GROUP BY - 如果订单表有主键（如
order_id），且其他字段都依赖它（即函数依赖），MySQL 5.7+ 的ONLY_FULL_GROUP_BY关闭时可能放行，但别依赖这个——跨库迁移时会崩 - 用子查询或 CTE 先聚合明细，再和订单表
JOIN，能彻底避开GROUP BY字段膨胀问题
明细金额求和时，注意 NULL 和重复 JOIN 导致的放大
SUM(detail_amount) 遇到 NULL 默认忽略，没问题；但更危险的是 JOIN 后笛卡尔式放大：比如一个订单关联 3 条明细，又不小心 JOIN 了客户表（1:1）或状态表（1:1），通常没事；但如果 JOIN 了多对一的标签表（一个订单有多个标签），就会让明细行翻倍，SUM 结果虚高。
排查方法：
- 先单独跑
SELECT order_id, COUNT(*) FROM order_detail GROUP BY order_id ORDER BY COUNT(*) DESC LIMIT 5，确认单订单最大明细数是否合理 - 加
SELECT order_id, COUNT(*) FROM orders o LEFT JOIN order_detail d USING(order_id) GROUP BY o.order_id HAVING COUNT(d.order_id) > [预期上限]，揪出异常订单 - 聚合前用
DISTINCT慎重——仅当确定重复是 JOIN 引起、且字段组合能唯一标识明细行时才考虑
性能关键：JOIN 字段和聚合字段要有索引
订单表和明细表 JOIN 靠 order_id，这个字段在明细表上必须有索引（通常是外键索引）；否则数据量一过万，全表扫描拖慢整个汇总。
另外，如果常按日期范围汇总（比如查“近7天订单总金额”），在订单表建 (order_date, order_id) 联合索引，能加速 WHERE order_date >= '2024-06-01' + JOIN + GROUP BY 整个流程。
没索引时典型现象：EXPLAIN 显示 type=ALL 或 rows 值极大；加完索引后 rows 应降到千分之一以内。
别忘了明细表的 order_id 索引要包含 amount 字段（覆盖索引），避免回表取值——尤其当明细表宽（字段多）时，这点省下的 IO 很可观。
