join多表时字段别名必须唯一，group by需显式指定表前缀如c.id、w.id；非聚合字段须全在group by中；left join配合coalesce处理零库存；索引缺失是性能主因。
JOIN 多表时字段别名必须唯一，否则 GROUP BY 会报错
直接 JOIN 商品、分类、仓库、库存四张表后，如果多张表都有 id 或 name 字段（比如 category.id 和 warehouse.id），GROUP BY 里写 id 就会报错：Column 'id' in group statement is ambiguous。这不是语法问题，是 SQL 引擎无法判断你要按哪张表的 id 分组。
实操建议：
- 所有参与
SELECT和GROUP BY的字段，一律用表别名前缀，例如c.name、w.code、i.quantity - 避免使用
SELECT *，只选真正需要聚合或分组的字段 - 如果要按分类+仓库双维度汇总，
GROUP BY必须显式写成GROUP BY c.id, w.id，不能只写GROUP BY c.id
GROUP BY 后的非聚合字段必须出现在 SELECT 列表中
比如你写了 SELECT c.name, SUM(i.quantity) FROM ... GROUP BY w.id，就会报错：Expression #1 of SELECT list is not in GROUP BY clause。MySQL 8.0+ 默认开启 ONLY_FULL_GROUP_BY，这是保护性限制，不是 bug。
常见场景是想展示“每个仓库里各分类的总库存”，但又希望显示分类名称——此时 c.name 必须和 w.id 一起进 GROUP BY，或者用 MAX(c.name) 这类聚合函数包裹（前提是每个 c.id 对应唯一 c.name）。
实操建议：
- 先确认分组键是否能唯一确定你要展示的描述字段（如分类名、仓库名）
- 若不能，优先补全
GROUP BY字段，而不是套聚合函数“糊弄”过去 - 临时关闭
ONLY_FULL_GROUP_BY是危险操作，上线环境严禁使用
LEFT JOIN 配合 COALESCE 处理零库存品类
用 INNER JOIN 会自动过滤掉没有库存记录的分类或仓库，导致汇总结果“消失”。比如某分类下所有仓库都无货，它就不会出现在结果里——这在报表中常被误认为数据缺失。
实操建议：
- 从主维度表（如
category）出发，用LEFT JOIN库存表inventory，再LEFT JOIN仓库表warehouse -
SUM(i.quantity)对空值返回NULL，用COALESCE(SUM(i.quantity), 0)转成 0 - 注意
WHERE条件写法：过滤条件如果加在ON子句里（如ON i.warehouse_id = w.id AND w.status = 'active'），能保留左表记录；若写在WHERE里（WHERE w.status = 'active'），会把NULL行干掉，变相退化为INNER JOIN
性能瓶颈往往卡在 JOIN 顺序和索引缺失上
四表 JOIN + GROUP BY 执行慢，90% 不是因为写法复杂，而是没建对索引。比如 inventory 表经常按 product_id 和 warehouse_id 查询，但只在 id 上有主键，没复合索引。
实操建议：
-
inventory表至少要有(warehouse_id, product_id)或(product_id, warehouse_id)的联合索引，顺序取决于你最常按哪个字段过滤 - 分组字段（如
c.id,w.id）对应的外键列，必须有索引，否则JOIN时走全表扫描 - 用
EXPLAIN看执行计划，重点关注type是否为ref或range，rows是否远小于表总行数
多层级汇总真正难的不是 SQL 写法，而是搞清业务口径——比如“可售库存”要不要扣减已锁定量，“分类”是按一级类目还是末级类目统计。这些逻辑一旦错，再漂亮的 SQL 也输出错误结果。
