运营日报显示订单 12,480 单,导出明细只有 12,431 行,差 49 条,连续三天差额一样。日志里能对上时间点,这种反而好排。

报表 SQL 用了 status <> 9 过滤,明细导出只查了 deleted_at is null。两处对“删除”的定义不同,被软删但状态没改的 49 条只进了汇总。报表和导出各写了一套 where。这一点先确认清楚,后面就不用反复试。

SELECT COUNT(*) FROM orders WHERE deleted_at IS NULL;
SELECT COUNT(*) FROM report_order_daily WHERE stat_date = '2026-03-01';

围绕「报表明细差额」排查时,命令行跑一遍比在面板里点十次有用,面板会替你做掉不少隐式操作。先做最小复现,能稳定跑出来的问题,排查成本会低一个数量级。

别只看报错的最后一行,往上看几行,真正的起因通常在上面。同类问题如果隔一段时间又出现,多半是某个定时任务或重启流程把改动冲掉了。

处理上按这个顺序:把过滤条件抽成公共视图或 CTE 两边共用;软删除只用 deleted_at 一个口径 不再看 status;加一条日检 SQL 对比汇总与明细行数;连续跑三天 确认差额为 0。

结果对不对很好判断,汇总和明细都返回 12,431,连续三天日检差额为 0。

作者 9823189