日报金额对不上八成因统计口径不一致，需确认业务定义（下单/支付/结算/入账时间）、检查字段来源与null处理、统一时区、避免隐式转换、核对数据源完整性、排查join类型与状态过滤、验证金额字段类型与单位、逐层定位最小可复现集。
查清楚统计口径是否一致
日报金额对不上，八成是统计口径没对齐。比如业务方说“当天支付成功金额”，但SQL里算的是create_time当天的订单，而实际支付可能延迟到账；或者用了pay_time，但部分订单支付时间为空、被过滤掉了。
- 确认业务定义：找产品或财务要明确定义——是按下单时间？支付时间？结算时间？还是资金实际入账时间？
- 检查字段来源：
pay_time是否允许为NULL？有没有用COALESCE(pay_time, create_time)这类兜底逻辑？ - 注意时区：数据库服务器时区和业务系统时区是否一致？
WHERE DATE(pay_time) = '2024-06-15'在UTC+8下可能漏掉UTC时间戳为6月15日23:00之后的数据 - 避免隐式转换：
WHERE pay_time >= '2024-06-15' AND pay_time 比<code>DATE(pay_time) = '2024-06-15'更安全，还能走索引
核对数据源是否完整且未被过滤
看起来跑出来的数偏小，大概率是WHERE条件过严，或者JOIN丢掉了部分记录。
- 查
LEFT JOIN是否误写成INNER JOIN：比如订单表左连支付表，但用了INNER JOIN，导致未支付订单直接被剔除 - 检查状态过滤：
WHERE status = 'paid'会不会把'partial_paid'或'refunded'（但已部分实收）也排除了？ - 注意软删除字段：
is_deleted = 0漏加？或者deleted_at IS NULL写成了deleted_at = NULL（后者永远不成立） - 子查询或CTE里是否提前
GROUP BY聚合，导致后续JOIN时行数变少？
验证金额字段是否被重复计算或类型出错
金额对不上，有时不是逻辑错，而是数值本身“长得像但不是它”。
- 查字段类型：
amount是DECIMAL(10,2)还是FLOAT？后者在累加时可能有精度误差，比如SUM(amount)显示999.9999999999999，四舍五入后变成1000.00，但业务按精确值比对就失败 - 排查重复记账：同一笔支付是否因订单拆分、退款重试等原因，在支付流水表里出现多条记录？加
COUNT(*)和COUNT(DISTINCT order_id)对比就能发现 - 注意单位：数据库存的是“分”还是“元”？
SUM(amount)/100漏了？或者前端展示时又除了一次100，导致结果变小100倍 - 检查负向金额：退款单是否用负数记录？
SUM(amount)会自动抵扣，但如果业务要求“实收净额”和“总支付额”分开统计，就得单独处理WHERE amount > 0
用最小可复现集逐层定位
别一上来就跑全量日报SQL。先锁定某一笔对不上的订单，逆向追踪。
- 找一个典型差异订单：
SELECT * FROM orders WHERE order_no = 'ORD123456'，看它的状态、支付时间、金额、是否关联多笔支付 - 在日报SQL里临时加
AND order_no IN ('ORD123456')，逐步放开WHERE条件，观察结果何时跳变 - 把最终SQL拆成中间步骤：先查基础订单集，再LEFT JOIN支付表，再WHERE过滤，每步
SELECT COUNT(*), SUM(amount)，确认哪一步数量/金额突变 - 对比线上和测试环境：同一SQL在两个环境跑，如果结果不同，优先查表数据一致性（比如同步任务延迟、归档策略差异）
真实场景里，最常被忽略的是时区 + 软删除 + 金额单位这三块。尤其当报表和BI工具结果不一致时，往往不是SQL写错了，而是BI建模层悄悄做了额外过滤或换算。
