临时表适合中小规模数据修改前后校验，关键在选准业务主键、显式列出比对字段并排除非业务字段；mysql需防临时表被子查询重复引用及事务中销毁，postgresql推荐用materialized cte配合full outer join和is not distinct from确保null安全比对。
怎么用临时表快速比出 SQL 修改前后的数据差异
直接结论：临时表不是万能的，但对中小规模数据（比如几万行以内）做修改前后校验，它是最可控、最不容易出错的方式。关键不在“建临时表”，而在“怎么选主键字段”和“怎么写比对逻辑”。
常见错误现象：SELECT * FROM temp_before EXCEPT SELECT * FROM temp_after 看似简洁，但只要某列含 NULL，结果就不可靠；或者没把时间戳、自增 ID 这类隐式变化字段排除，导致“明明没改数据，却显示有差异”。
- 先确认业务主键：必须是能唯一标识一行记录的字段组合，比如
order_id+sku_id，不能只用单个id（万一修改逻辑本身影响了主键生成） - 临时表结构要严格一致：字段名、顺序、类型（尤其是
TIMESTAMP和DATETIME在 MySQL 里行为不同） - 避免 SELECT *：显式列出比对字段，把不参与校验的字段（如
updated_at、version）明确剔除
MySQL 里建临时表时要注意哪些坑
MySQL 的 CREATE TEMPORARY TABLE 只在当前会话可见，看起来很安全，但容易忽略两个硬限制：一是临时表不能被子查询多次引用（会报 Table 'xxx' doesn't exist），二是事务提交后临时表自动销毁——如果你在存储过程中分多步操作，中间 COMMIT 了，后续就查不到临时表。
- 别在子查询里反复引用同一张临时表，改用 CTE（MySQL 8.0+）或再建一张临时表缓存中间结果
- 如果修改语句本身在事务中执行，临时表必须在事务开启后、修改前创建，且整个流程不能主动
COMMIT - 字段类型尽量用
NOT NULL：临时表默认继承原表的 NULL 属性，但比对时NULL = NULL不成立，会导致漏掉差异
PostgreSQL 怎么用 WITH 查询替代临时表做差异比对
PostgreSQL 的 WITH 支持递归和多次引用，比 MySQL 临时表更灵活，但要注意物化行为：默认情况下，CTE 是“非物化”的，意味着每次被引用都会重新执行，如果前后快照查询本身很慢，性能可能翻倍。
- 加
MATERIALIZED关键字强制物化（PG 12+）：WITH before AS MATERIALIZED (SELECT ...) , after AS MATERIALIZED (SELECT ...) - 比对时优先用
FULL OUTER JOIN：能同时捕获“只在 before 有”“只在 after 有”“字段值不同”三类情况 - 字段值比较必须用
IS NOT DISTINCT FROM替代!=，否则NULL值永远被判为“不同”
比对结果里出现大量“看似相同实则不同”的记录怎么办
本质问题往往出在数据类型隐式转换或精度丢失上。比如把 DECIMAL(10,2) 存进临时表时用了 FLOAT，或者字符串字段带不可见空格、换行符、全角/半角字符混用。
- 用
LENGTH()和HEX()检查字符串：比如SELECT id, LENGTH(name), HEX(name) FROM temp_before WHERE id = 123 - 数值字段统一转成字符串再比对：
CAST(price AS TEXT)，避开浮点误差和舍入规则差异 - 时间字段统一转成秒级时间戳或 ISO 格式字符串，别直接比
DATETIME字面量
真正麻烦的不是语法怎么写，而是你得先想清楚：这次修改到底应该影响哪些字段？哪些字段的变更属于预期之内？比对脚本再准，也救不了需求定义模糊的问题。
