用自增ID做版本关联时JOIN漏最新版，因历史表仅存变更快照而最新态在主表；正确做法是UNION ALL主表与历史表后按id+时间戳排序取首条，并用TIMESTAMP类型存时间避免时区错位。
用自增ID做版本关联时，为什么JOIN结果总是漏掉最新版？
因为历史表里通常只存「变更快照」，而最新状态在主表；直接 LEFT JOIN 历史表会丢掉没被修改过的记录。正确做法是把主表当「当前态」，历史表当「变更日志」，用 UNION ALL 合并后再按 id + version_id（或时间戳）排序取首条。
常见错误写法：SELECT * FROM users u LEFT JOIN user_history h ON u.id = h.user_id —— 这只能查到有历史记录的用户，且无法区分哪条是最新。
- 推荐结构：主表字段 +
COALESCE(h.updated_at, u.updated_at)统一时间基准 - 若历史表用自增
id记录顺序，可用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY id DESC)标记版本序号 - 注意：自增ID不等于时间先后，高并发下可能乱序，必须配合
created_at或显式版本号校验
时间戳回溯遇到夏令时/时区转换，查询结果错位怎么办？
updated_at 存的是本地时间（如 DATETIME）时，跨时区回溯会出错。比如北京用户凌晨1点改资料，数据库设为 Asia/Shanghai 但应用层用 UTC 写入，再用 BETWEEN '2024-06-01' AND '2024-06-02' 查，就可能漏掉或重复。
- 统一用
TIMESTAMP类型（自动转UTC存储），避免时区隐式转换 - 回溯某时刻状态，别用
WHERE updated_at ，而要用 <code>WHERE (updated_at, id) 复合条件防并发写入时间相同 - MySQL 8.0+ 可用
AS OF TIMESTAMP（需开启binlog_row_image=FULL），但仅限支持的引擎（如InnoDB + 归档日志）
如何高效查「某个时间点每个用户的最后有效版本」？
典型场景：审计导出「2024-05-20 12:00:00 时所有用户的状态」。不能对每个用户跑子查询，性能爆炸。
核心思路是：先筛选出所有在目标时间前发生的变更（含主表当前行），再按用户分组取最新一条。
- 关键技巧：把主表也当作一条「虚拟历史记录」，
SELECT id, name, updated_at, 0 AS is_history FROM users UNION ALL SELECT user_id, name, updated_at, 1 FROM user_history - 加
WHERE updated_at 后，用 <code>ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC, is_history DESC)——is_history DESC确保主表记录优先于同时间的历史记录 - 索引必须包含
(user_id, updated_at)或(updated_at, user_id)，否则排序开销极大
PostgreSQL vs MySQL 在版本回溯上的关键差异
PostgreSQL 的 LATERAL 和窗口函数支持更自然，MySQL 8.0 虽支持窗口函数，但 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 在大表上容易内存溢出。
- PG 推荐写法：
SELECT DISTINCT ON (user_id) * FROM (SELECT * FROM user_history UNION ALL SELECT *, NOW() AS updated_at FROM users) t ORDER BY user_id, updated_at DESC - MySQL 必须加
GROUP BY+MAX(updated_at)子查询，或用变量模拟ROW_NUMBER（5.7及以前） - 两者都避不开：历史表膨胀后，
updated_at字段必须建索引，且定期归档旧数据——否则单次回溯扫描几百万行很常见
实际中最容易被忽略的是「主表与历史表字段一致性」：比如主表有 status，历史表漏了该字段，或者类型不一致（TINYINT vs ENUM），导致 UNION 失败或隐式转换出错。上线前务必用 DESCRIBE 或 \d 对比结构。
