SQL快照表核心目标是低成本高效率记录历史状态，需先明确业务需求再选全量或增量模式；字段须含surrogate_key、business_key、start_date/end_date、is_current等，推荐用MERGE或CDC自动化实现。
SQL快照表的核心目标是低成本、高效率地记录数据的历史状态，而不是简单地“每次改都留一行”。关键在于明确业务需求——是需要完整时间线追溯？还是只需知道某条记录“当前有效版本”和“上一个版本”？设计前先想清楚这点，能避免过度设计或功能缺失。
快照表的两种典型模式
根据变更频率和查询场景，主流做法分两类：
- 全量快照表（Daily Snapshot）：每天固定时刻把主表全量数据插入一次，加一列 snapshot_date。适合指标类分析，比如“每天各商品库存余额”，查起来快，但存储增长快，且无法定位到某次具体修改。
- 增量快照表（CDC + SCD Type 2）：只在数据实际变化时才新增一行，用 start_date / end_date + is_current 标记生命周期。适合追踪明细变化，比如“用户地址变更历史”，空间省、语义清，但写入逻辑稍复杂，需处理更新与失效。
字段设计要点（以SCD Type 2为例）
除了原始业务字段，必须包含以下几项才能构成可追溯的快照链：
- surrogate_key：代理主键（如自增ID或UUID），用于唯一标识每一行快照，不依赖业务字段。
- business_key：业务主键（如 user_id、product_id），用于关联原始实体。
- start_date / end_date：生效起止时间，end_date 常用 '9999-12-31' 表示当前有效；更新时需将旧记录 end_date 改为前一秒，并插入新行。
- is_current：布尔标记，便于快速筛选最新版本（也可用 end_date = '9999-12-31' 替代，但加字段更直观）。
- version / change_hash（可选）：version 自增序号；change_hash 可存字段拼接后的MD5，用于快速比对是否真有变化，避免无效快照。
自动化快照生成建议
靠人工INSERT不现实，推荐结合数据库能力或ETL工具实现闭环：
- 用 MERGE（SQL Server / Oracle）或 INSERT ... ON CONFLICT（PostgreSQL）做“存在则更新、不存在则插入”的原子操作。
- MySQL 可借助触发器捕获 UPDATE/INSERT，但注意性能影响；更稳的方式是解析 binlog（如用 Canal/Flink CDC）同步变更到快照表。
- 数仓场景下，用调度任务（Airflow / DolphinScheduler）每日跑一次全量快照，或每小时拉取增量变更并合并进SCD表。
基本上就这些。快照不是越细越好，也不是越全越对。匹配业务查询习惯、控制存储成本、保障数据一致性，三者平衡好，才是好设计。
