row_number()比max()+子查询更可靠，因其能精准关联最新版本的完整行数据；而max(version)仅返回最大值，无法确保对应行的updated_at、status等字段一致性，尤其在同版本多记录或版本非严格递增时结果不可控。
为什么 ROW_NUMBER() 比 MAX() + 子查询更可靠？
直接用 MAX(version) 找最新版本在多数场景下会失败——它只能拿到最大版本号，但无法关联到该版本对应的完整行数据（比如 updated_at、status 等字段），尤其当存在多条同版本记录或版本号非严格递增时，结果不可控。
真正安全的做法是用窗口函数按主键分组、按时间或版本排序后取首行：
SELECT id, status, updated_at, version
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY id ORDER BY version DESC, updated_at DESC) AS rn
FROM history_table
) t
WHERE rn = 1;
-
PARTITION BY id确保每个实体独立排序，不跨 ID 混淆 -
ORDER BY version DESC, updated_at DESC是双重保险：版本相同时靠时间戳决胜 - 避免只写
ORDER BY version DESC——数据库可能返回任意一条，结果不稳定
MySQL 5.7 或更老版本没有 ROW_NUMBER() 怎么办？
必须退回到相关子查询或自连接，但性能和可读性明显下降。最常用且兼容性最好的方案是用 LEFT JOIN 自连接找“不存在更大版本”的记录：
SELECT h1.id, h1.status, h1.updated_at, h1.version FROM history_table h1 LEFT JOIN history_table h2 ON h1.id = h2.id AND (h2.version > h1.version OR (h2.version = h1.version AND h2.updated_at > h1.updated_at)) WHERE h2.id IS NULL;
- 关键点是
ON条件里用OR处理版本相同但时间更新的情况 - 如果只比
version，会漏掉同版本下时间更晚的记录 - 这个写法在 MySQL 5.7、PostgreSQL 9.5、SQL Server 2008 都能跑，但数据量大时需确保
(id, version, updated_at)有联合索引
PostgreSQL 中用 DISTINCT ON 是不是更简洁？
是，而且语义清晰、性能通常优于窗口函数，但仅限 PostgreSQL：
SELECT DISTINCT ON (id) id, status, updated_at, version FROM history_table ORDER BY id, version DESC, updated_at DESC;
-
DISTINCT ON必须配合ORDER BY，且排序字段顺序要和DISTINCT ON一致 - 第一行匹配即取，所以
ORDER BY的优先级必须明确：先按id分组，再按version降序，最后用updated_at保底 - 不能写成
ORDER BY id, updated_at DESC, version DESC——那样会按时间优先，可能取错版本
WHERE 条件下推是否影响最新值准确性？
影响很大。如果在最外层加 WHERE status = 'active'，会先过滤再取最新；但如果想取“每个 ID 最新记录中状态为 active 的那些”，逻辑就完全不同。
- 错误写法（先过滤再聚合）：
SELECT ... FROM (...) t WHERE t.status = 'active';
→ 可能某个 ID 最新记录是inactive，直接被丢弃 - 正确写法（先取最新，再筛选）：
SELECT * FROM (/* 上述 ROW_NUMBER 查询 */) t WHERE t.status = 'active';
- 更复杂的需求（如“最新记录是 active，且历史中至少出现过一次 pending”）必须用
EXISTS或BOOL_OR()聚合，不能靠简单嵌套解决
嵌套层级越深，越容易忽略条件作用域——每次加 WHERE 前，先问一句：这条件是筛原始数据，还是筛已选出的最新行。
