SQL更新前用CREATE TABLE AS建带时间戳的快照表，明确列名、及时建索引；对比用LEFT JOIN查字段级变更更可控，注意NULL、时间精度、JSON标准化及枚举类型一致性。

SQL 更新前怎么保存快照？用 CREATE TABLE AS 最省事

更新前没留痕，差异数不出来——这是最常踩的坑。别等 UPDATE 完再想“刚才到底改了哪些行”，快照必须在执行前建好。

最直接的方式是用 CREATE TABLE AS 复制当前状态，名字带时间戳或业务标识，比如：

CREATE TABLE orders_snapshot_20240520 AS SELECT * FROM orders;

• 别用 SELECT * 如果表有大字段（如 TEXT、JSONB），会拖慢快照创建；明确列出关键列更稳
• 快照表默认没索引，后续对比时 JOIN 或 WHERE 会很慢，建完立刻加主键或常用查询字段的索引
• 某些数据库（如 PostgreSQL）支持 WITH NO DATA 快速建结构，但那不是快照——它不存数据，不能用来比差异

对比两表差异：用 EXCEPT 还是 LEFT JOIN？看你要查什么

要找“只在新表有、旧表没有”的记录，EXCEPT 简洁；但想同时看到新旧值、判断字段级变更，LEFT JOIN 更可控。

比如查被修改的订单金额：

SELECT a.id, a.amount AS old_amount, b.amount AS new_amount
FROM orders_snapshot_20240520 a
JOIN orders b ON a.id = b.id
WHERE a.amount != b.amount;

• EXCEPT 对 NULL 不友好——NULL != NULL 返回 true，容易漏掉空值变更，得额外处理 IS NOT DISTINCT FROM
• 用 JOIN 时，确保两边都对齐了主键或唯一标识，否则一对多会爆炸出重复行
• 如果表很大，先用 WHERE updated_at BETWEEN ... 限制范围，别全表扫

辅助表设计要注意字段可比性：时间、JSON、枚举都容易翻车

快照只是复制了当时的数据，但有些字段天生不适合直接比：时间精度不一致、JSON 格式化不同、枚举值映射变化……这些都会让差异结果失真。

• 时间字段统一转成 TIMESTAMP WITHOUT TIME ZONE 或截断到秒，避免毫秒/时区导致“看起来变了其实没变”
• JSON 字段别直接 !=，用数据库自带函数标准化后再比，比如 PostgreSQL 的 jsonb_strip_nulls() + jsonb_pretty()
• 如果业务里用了字符串枚举（如 'active'/'inactive'），更新时改成数字码（1/0），快照和现表类型不一致会导致隐式转换失败或误判

UPDATE 后立刻删快照？先确认是否真不需要了

很多人把快照当临时工，UPDATE 一跑完就 DROP TABLE。但线上出问题要回溯时，发现快照没了，只能翻备份、查 binlog——代价高得多。

• 快照表名带上操作人、环境（如 orders_snapshot_20240520_prod_alice），方便定位归属
• 保留周期按风险定：核心配置表建议留 7 天，批量任务中间态留 24 小时，开发环境可当天清
• 不要依赖快照做长期审计——它没事务上下文、没操作人信息、没变更原因，只是数据切片

真正难的不是建快照或写对比 SQL，而是想清楚：这个变更到底影响哪些业务逻辑，而不仅仅是“哪几行变了”。字段语义漂移、外键约束松动、下游缓存未失效……这些都不会出现在 SELECT * FROM ... WHERE old != new 的结果里。