最可靠方式是用EXCEPT比对字段名、顺序、类型完全一致的聚合结果，需统一浮点精度、NULL处理、时区及排序规则，先校验结构再比内容。
怎么用脚本比对两个SQL分组结果是否一致
直接比对 GROUP BY 后的聚合结果，最可靠的方式不是肉眼扫，而是把两边查出来的结果导出成临时表，用 EXCEPT 或 NOT EXISTS 做集合差。重点不是“查得对不对”，而是“两边结构、精度、空值处理是否完全一致”。
- 必须确保两段 SQL 返回字段名、顺序、数据类型完全相同；否则
EXCEPT会静默失败或误报（比如INTvsBIGINT、VARCHAR(50)vsVARCHAR(100)） - 浮点数聚合（如
SUM(price)）要统一转成DECIMAL再比，否则ROUND(SUM(x), 2)和CAST(SUM(x) AS DECIMAL(18,2))在某些引擎里结果可能差 0.01 -
NULL在分组键中会被视为同一组，但不同数据库对GROUP BY NULL的行为有差异；建议提前用COALESCE(col, '__NULL__')统一兜底
为什么不能直接用 SELECT * FROM a EXCEPT SELECT * FROM b
因为 EXCEPT 是逐行全字段比对，只要有一列类型隐式转换失败（比如一边是 TIMESTAMP，一边是 DATE），整条语句就报错——常见错误是 ERROR: set operations require compatible column types。它不告诉你哪一列不兼容，只报语法层失败。
- 先运行
SELECT column_name, data_type FROM information_schema.columns WHERE table_name IN ('a', 'b') ORDER BY table_name, ordinal_position看字段对齐情况 - 如果字段名不同但语义相同（如
total_amtvsamount_sum），必须显式别名对齐：SELECT ... AS amount_sum FROM a EXCEPT SELECT ... AS amount_sum FROM b - PostgreSQL 支持
EXCEPT ALL，但 MySQL 不支持；MySQL 得改用LEFT JOIN ... WHERE b.key IS NULL模拟
如何写一个可复用的校验脚本（以 PostgreSQL 为例）
核心思路：把待比对的两段 SQL 封装成 CTE，再用 UNION ALL + COUNT(*) 快速判断是否完全一致，比 EXCEPT 更早暴露差异。
WITH src AS (SELECT shop_id, SUM(sales) AS total FROM sales_2024 GROUP BY shop_id),
tgt AS (SELECT store_id AS shop_id, ROUND(SUM(revenue), 2) AS total FROM fact_sales GROUP BY store_id)
SELECT
(SELECT COUNT(*) FROM src EXCEPT SELECT COUNT(*) FROM tgt) = 0 AS row_count_match,
(SELECT COUNT(*) FROM (SELECT * FROM src EXCEPT SELECT * FROM tgt) t) = 0 AS content_match;- 第一行检查行数是否一致，秒级返回；如果不等，后面不用跑了
- 第二行才是真内容比对，但注意：如果
src和tgt字段类型不一致，这句会直接报错，所以务必先做类型校验 - 别省略
ROUND(..., 2)这类显式精度控制——浮点误差在聚合后会放大，199.99999999999997和200.00被当成不同值
哪些场景下脚本会“看起来通过，其实错了”
最典型的是时区、字符集、排序规则（collation）导致的隐式转换。比如 GROUP BY name，一边用 utf8mb4_0900_as_cs，一边用 utf8mb4_unicode_ci，‘café’ 和 ‘cafe’ 可能被归为同一组，也可能不归——这种差异不会报错，但结果不一致。
- 检查当前 session 的
SHOW lc_collate（PostgreSQL）或SELECT @@collation_database（MySQL） - 字符串聚合（如
STRING_AGG(name, ',')）要注意分隔符是否含空格、换行，不同数据库默认行为不同 - 分区表或物化视图未刷新时，
tgt查询可能读到旧快照，而src是实时查，这种“时间差”问题只能靠加时间戳字段或强制REFRESH MATERIALIZED VIEW规避
真正难的从来不是写脚本，而是确认两边 SQL 所依赖的数据源、函数定义、配置参数是否真的“站在同一套现实”里。漏掉一个 SET timezone = 'UTC'，整个校验就失去意义。
