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 的结果里。
