必须自动化sql结果校验，因人工易漏错、不可复现、难追溯；需遵循断言优先、避免隐式转换、时间范围对齐三原则，并纳入CI/CD流程管理。
应该，而且必须自动化——手工核对 SQL 查询结果在数据量稍大或校验逻辑稍复杂时，几乎必然漏错、不可复现、无法追溯。
为什么人工校验 SQL 结果不可靠
人眼比对两列数字或几十行文本，容易跳行、忽略空格/大小写/时区差异；临时写的校验 SQL 没有版本管理，下次想复现可能连 WHERE 条件都记不清；更关键的是，没人会每天手动跑一遍「昨日订单金额 = 支付表 sum + 退款表 sum」这种逻辑。
- 常见错误现象：
NULL值被当成0参与计算，LEFT JOIN导致重复计数却没加DISTINCT - 使用场景：etl 调度后、报表上线前、跨库迁移完成时
- 性能影响：校验 SQL 若未加索引提示或写成全表扫描，可能拖慢整个流水线
用 SQL 写校验逻辑的三个关键原则
校验不是写业务查询，目标是“快速暴露不一致”，不是“查得全”。重点在断言（assertion）而非展示。
- 只返回异常：用
CASE WHEN+HAVING或子查询包裹，让结果集为空才代表通过，例如：select 'total_mismatch' AS error FROM (SELECT SUM(amount) AS s1 FROM orders WHERE dt='2024-06-01') t1 JOIN (SELECT SUM(payment) AS s2 FROM payments WHERE dt='2024-06-01') t2 ON t1.s1 != t2.s2; - 避免隐式类型转换：显式用
CAST(x AS DECIMAL(18,2))，否则int和Float比较可能因精度丢数 - 时间范围必须对齐：校验「昨日数据」时，所有表都要用同一
WHERE dt = CURRENT_DATE - INTERVAL '1' DAY，别一个用created_at >= ...一个用dt = ...
自动化执行不能只靠定时 SQL 脚本
光把校验语句塞进 airflow 的 PostgresOperator 不够——失败了没人知道，通过了也没留痕，更没法关联到具体数据任务。
- 必须绑定上下文：在脚本开头用注释写明校验目的，例如
-- assert: order_count in fact_orders == count(*) from ods_order where status='paid' - 失败要可定位：输出中包含实际值、期望值、偏差率，例如
expected=10000, actual=9872, diff=-1.28% - 兼容性注意：不同引擎对
ASSERT语法支持不一，postgresql有ASSERT，mysql和Trino得靠SELECT CASE+ 非空判断模拟
最常被忽略的是校验逻辑本身的变更管理——它和业务代码一样需要 git 提交、Code Review、测试环境预跑。一旦校验 SQL 出错，它就会变成“假阴性”的盲区，比不校验还危险。