先用SELECT DISTINCT比对关联字段值，确认映射关系；再统一处理前导零或字母后缀差异；LEFT JOIN后出库量为NULL需检查状态过滤和WHERE误用；核对总量要防明细重复和时间范围不一致；多指标聚合用相关子查询避免GROUP BY冲突。

JOIN 时库存表和出库表的主键对不上怎么办

拿 product_id 直接去做 JOIN，翻车的概率其实不低。

库存表里存的往往是 sku_code，出库单那边却可能叫 item_no 或 goods_id。表面看只是字段名对不上，真正的问题通常在于：业务系统之间压根没有统一的编码体系。

更稳妥的做法，是先用 SELECT DISTINCT 把两边可能关联的字段值分别查出来。 先肉眼对比前 10 条，确认它们到底能不能一一映射。

• 前导零不一致：比如库存里是 '00123'，出库里是 '123'。
• 处理方式：在 JOIN 条件里统一做格式处理，常见方式就是用 TRIM(LPAD(...)) 或 CAST(... AS CHAR)。
• 字母后缀差异：如果其中一边还带着字母后缀，比如 'A001-RED' 对 'A001'。
• 处理方式：这时不能硬连，得先借助 SUBSTRING_INDEX 或正则把基准码提取出来。

LEFT JOIN 库存表后发现出库数量为 NULL

这通常不是数据丢了，而是出库记录根本没匹配上库存行。

• 可能该商品从未被录入库存表。
• 也可能状态字段被过滤掉了，比如库存表里 status = 'active'，但新上架商品还没更新状态。

还要重点检查 JOIN 条件外是否误加了 WHERE 子句。

把 WHERE out.stock_date > '2024-01-01' 放在 JOIN 后，会把左表没匹配的库存行也过滤掉。

正确做法是把这类条件移到 ON 子句里，写成 ON inv.sku = out.item_no AND out.stock_date > '2024-01-01'。

另外，还要确认出库表是否有重复单据号导致笛卡尔积。

用 COUNT(*) 和 COUNT(DISTINCT order_no) 对比，能快速识别。

核对总量时 SUM 出库量比库存变动大很多

这类问题通常出在两个地方。

先看明细重复累计

出库表里，同一张单据往往不止一行明细。比如一个订单被拆成了三条出库记录。

但库存表这边，通常是按 SKU 做汇总的。这样一来，如果直接写 SUM(out.qty)，结果就很容易被重复累计。

更稳妥的做法，是先按照 order_no, sku 把出库量预先聚合好。

SELECT sku, SUM(qty) AS total_out FROM out_log GROUP BY sku

然后再去和库存表 JOIN。

再看时间范围是否对齐

另一个很容易踩的坑，是时间范围没对齐。

库存快照取的是“日终”口径，而出库表查的是全天流水。

也就是说，如果要核对 1 月 1 日的库存，出库数据就必须限定为 out_time BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59'。

不能只拿日期字段去做 = '2024-01-01'。原因也不复杂，多数数据库会把时间部分忽略掉，实际效果往往等价于 >= '2024-01-01'。

需要同时看库存余量和累计出库量，但 GROUP BY 冲突

想在同一结果里显示 inv.current_qty 和 SUM(out.qty)，又不想丢失零出库的 SKU，就不能简单 GROUP BY 库存表字段。

稳妥做法是两层嵌套。 外层 SELECT 库存字段，内层用相关子查询算出库量。

SELECT inv.sku, inv.current_qty, (SELECT COALESCE(SUM(qty), 0) FROM out_log o WHERE o.item_no = inv.sku AND o.out_time <= '2024-01-01') AS total_out FROM inventory inv

如果性能扛不住，出库表超百万行，就把子查询换成 LEFT JOIN + 子查询聚合后的临时表，或者加复合索引 (item_no, out_time)。

注意 MySQL 8.0+ 支持窗口函数，但此处不适用——因为要关联不同表，不是同表内分区统计。

核对前要先统一业务口径

真正卡住人的往往不是语法，而是两边系统对“同一商品”的定义粒度不同。

库存按规格编码，出库按销售单元。一个 SKU 在出库里可能对应多个 batch_no 或 warehouse_id。

核对前得先和业务方确认“什么才算对得上”。