必须自动化SQL结果校验，因人工易漏错、不可复现、难追溯；需遵循断言优先、避免隐式转换、时间范围对齐三原则，并纳入CI/CD流程管理。
应该，而且必须自动化——手工核对 SQL 查询结果在数据量稍大或校验逻辑稍复杂时，几乎必然漏错、不可复现、无法追溯。
为什么人工校验 SQL 结果不可靠
人眼比对两列数字或几十行文本，容易跳行、忽略空格/大小写/时区差异；临时写的校验 SQL 没有版本管理，下次想复现可能连 WHERE 条件都记不清；更关键的是，没人会每天手动跑一遍「昨日订单金额 = 支付表 sum + 退款表 sum」这种逻辑。
- 常见错误现象：
NULL值被当成0参与计算，LEFT JOIN导致重复计数却没加DISTINCT - 使用场景：ETL 调度后、报表上线前、跨库迁移完成时
- 性能影响：校验 SQL 若未加索引提示或写成全表扫描，可能拖慢整个流水线
用 SQL 写校验逻辑的三个关键原则
校验不是写业务查询，目标是“快速暴露不一致”，不是“查得全”。重点在断言（assertion）而非展示。
openclaw-github-config-impact
下载
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 只返回异常：用
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 出错，它就会变成“假阴性”的盲区，比不校验还危险。
