COUNT(*) 和 GROUP BY 可快速发现行数或分组分布差异：先比聚合层面是否一致，如各 status 数量，能暴露同步遗漏或逻辑偏差；须确保 WHERE 条件（如时间范围、is_deleted）一致，GROUP BY 列必须覆盖所有非聚合列，避免语法报错。
用 COUNT(*) 和 GROUP BY 快速发现行数或分组分布差异
两张表结构相同但数据疑似不一致时，最直接的判断方式不是逐行比对，而是先看聚合层面是否“对得上”。比如源表和目标表的某字段分组后行数是否一致，能快速暴露同步遗漏、重复插入或过滤逻辑偏差。
常见错误现象：COUNT(*) 结果不同，但没进一步定位是哪几组出问题；或者用了 SELECT * 配合 GROUP BY 导致语法报错（MySQL 5.7+ 默认 sql_mode 严格）。
- 务必在
GROUP BY中包含所有非聚合列，否则会报Expression #1 of SELECT list is not in GROUP BY clause - 对比前先确认两表时间范围、状态字段（如
is_deleted = 0）是否完全一致，否则聚合结果天然失真 - 对大数据量表，加
LIMIT 100先看头部差异，避免全表扫描卡住
示例：查订单表中各 status 的数量是否与备份表一致
SELECT status, COUNT(*) AS cnt FROM orders GROUP BY status UNION ALL SELECT status, COUNT(*) AS cnt FROM orders_bak GROUP BY status ORDER BY status, cnt;
用 MIN()/MAX() 检查关键字段取值范围是否越界
某些字段（如 created_at、amount）本应落在合理区间，若一张表出现异常极值，往往说明 ETL 过程中类型转换失败、默认值填充错误或脏数据混入。
使用场景：核对每日增量同步后，新数据的时间戳是否全部晚于上一次同步点；或金额字段是否意外出现负数/超大值。
-
MIN(created_at)比预期早，可能是历史数据被误重放 -
MAX(amount)突然跳到999999999，大概率是源系统用魔数表示空值，而目标表未做清洗 - 注意 NULL 值对
MIN/MAX的影响：它们会被忽略，若想包含 NULL，需配合CASE WHEN显式处理
示例：检查用户表中 age 是否超出常规范围
SELECT 'src' AS src, MIN(age), MAX(age) FROM users UNION ALL SELECT 'dst' AS src, MIN(age), MAX(age) FROM users_dst;
用 SUM(CHECKSUM) 或 BIT_XOR 快速校验整表内容一致性
当需要确认两张表“内容完全一样”且无法用主键逐条 JOIN 时（比如无主键、数据量极大、或只关心逻辑等价），可对每行生成哈希再聚合。但注意：CHECKSUM() 在 MySQL 中行为不稳定（字符串排序敏感、大小写敏感），PostgreSQL 没原生 CHECKSUM 函数，SQL Server 的 BINARY_CHECKSUM 有碰撞风险。
更稳妥的做法是用确定性表达式构造行级标识，再聚合比对：
- MySQL 8.0+ 可用
SUM(SHA2(CONCAT_WS('|', col1, col2, ...), 256))，但性能差，仅适合小表 - 通用做法：用
BIT_XOR对数值型主键或自增 ID 做异或（要求两表 ID 集合完全一致，且无重复），BIT_XOR(id)结果相同 ≠ 内容相同，但结果不同一定不一致 - 真正可靠的方案是导出两表排序后的文本，用外部工具 diff —— SQL 层只负责快速证伪，不追求证真
示例：用字符串拼接模拟轻量级校验（仅用于示意，勿用于生产）
SELECT SUM(LENGTH(CONCAT_WS('|', id, name, email))) AS len_sum,
COUNT(*) AS row_cnt
FROM users;
为什么 LEFT JOIN ... WHERE right IS NULL 不适合“快速”对比
这是最常被推荐的方法，但它在多数真实场景下并不“快”：一旦缺少合适索引，就会触发全表扫描 + 嵌套循环；若两表都超百万行，执行可能长达数分钟甚至超时。它解决的是“找出差异行”，而不是“快速判断是否存在差异”。
真正需要“快速”的时候，优先走聚合路径 —— 行数、分布、极值、校验和，这些都能利用索引或仅扫描必要字段，响应通常在秒级内。
- 只有当你已经确认聚合层一致，且必须定位具体哪几行不同时，才用
LEFT JOIN或NOT EXISTS - 用
NOT EXISTS通常比LEFT JOIN ... IS NULL更易命中索引，尤其当右表有复合索引覆盖关联字段时 - 别忘了加
EXPLAIN看执行计划：如果出现type: ALL或rows接近表总行数，说明这条路走不通
差异的本质不在语法多炫酷，而在你是否清楚每一行聚合结果背后对应多少原始数据、索引能否覆盖、以及 NULL 到底算不算“相同”。
