直接用 MAX(version) 会漏掉最新快照，因“最新”取决于 updated_at 时间戳而非 version 值；version 可能为字符串、滞后或回滚，不可靠；应优先按 updated_at DESC + version DESC 排序，用 ROW_NUMBER() 取每 product_id 首行。
为什么直接用 MAX(version) 会漏掉最新快照？
因为“最新快照”不是指单条记录的最高版本号，而是每个实体（比如每个 product_id）在历史表中**时间上最近一次被更新**对应的完整行。如果只按 version 取最大值，会忽略同一版本下多条记录、或版本号不严格递增（如补丁回填、人工修正）的情况。真正可靠的锚点通常是 updated_at 或 created_at 时间戳。
用 ROW_NUMBER() 窗口函数按实体分组排序取首行
这是最直观且兼容性较好的方案（PostgreSQL / SQL Server / Oracle / MySQL 8.0+ 都支持）。核心是给每组数据按时间倒序编号，再过滤出编号为 1 的行：
SELECT product_id, name, price, updated_at, version
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY product_id
ORDER BY updated_at DESC, version DESC
) AS rn
FROM product_history
) ranked
WHERE rn = 1;注意两个细节：
- PARTITION BY product_id 确保每个商品独立排序
- ORDER BY updated_at DESC, version DESC 是防兜底：当时间戳相同时，用版本号辅助判别“更权威”的快照
MySQL 5.7 或 SQLite 等不支持窗口函数时怎么办？
得用相关子查询或连接方式模拟“每组最大时间”。但必须小心性能和语义陷阱：
- 别写
WHERE updated_at = (SELECT MAX(updated_at) FROM ...)—— 如果一个product_id有多个记录共享同一最大时间，会返回多行，破坏“快照唯一性” - 推荐用
INNER JOIN+ 聚合子查询，确保每组只匹配一条（利用主键或唯一组合）：
SELECT h1.product_id, h1.name, h1.price, h1.updated_at, h1.version FROM product_history h1 INNER JOIN ( SELECT product_id, MAX(updated_at) AS max_updated FROM product_history GROUP BY product_id ) h2 ON h1.product_id = h2.product_id AND h1.updated_at = h2.max_updated -- 若仍有重复，再加一层去重逻辑，例如： -- WHERE (h1.product_id, h1.updated_at, h1.version) IN ( -- SELECT product_id, updated_at, MAX(version) -- FROM product_history GROUP BY product_id, updated_at -- );
为什么不能只依赖 version 字段做嵌套过滤？
现实中的版本字段常有以下问题：
-
version是字符串型（如'v2.1.0'），MAX()比较结果不可靠 - 不同业务线写入时未同步维护
version，导致它滞后于实际变更时间 - 存在“版本回滚”操作，高版本记录反而比低版本更早写入
所以任何仅基于 version 的嵌套查询（比如 WHERE version = (SELECT MAX(version) FROM ...)）在生产环境都容易产出错误快照。时间戳才是事实依据，version 最多作为二级排序或校验字段。
