SQL 数据校验是否应该自动化？

必须自动化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='2025-06-01') t
  1 JOIN (SELECT SUM(payment) AS s2 FROM payments WHERE dt='2025-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 出错，它就会变成“假阴性”的盲区，比不校验还危险。