正确做法是用 ROW_NUMBER() 标出每组最新记录再筛选更新：WITH latest AS (SELECT user_id, score, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC, id DESC) AS rn FROM source_table) UPDATE target_table t SET latest_score = l.score FROM latest l WHERE t.user_id = l.user_id AND l.rn = 1；MySQL 5.7 需用双层子查询或自关联替代。
用窗口函数找最新记录再 JOIN 更新
直接用 GROUP BY 配合 MAX(time) 容易丢字段（比如拿不到对应那条记录的 status），正确做法是先用 ROW_NUMBER() 标出每组最新的一条，再筛选出来参与更新。
假设表 source_table 有字段 id、user_id、score、updated_at，要按 user_id 取最新一条，更新到 target_table 的 latest_score 字段：
WITH latest AS (
SELECT user_id, score,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn
FROM source_table
)
UPDATE target_table t
SET latest_score = l.score
FROM latest l
WHERE t.user_id = l.user_id AND l.rn = 1;
-
ROW_NUMBER()必须搭配PARTITION BY和明确的ORDER BY，否则无法保证“每组最新” - PostgreSQL 和 SQL Server 支持这种带
FROM的UPDATE；MySQL 8.0+ 也支持，但 MySQL 5.7 只能用多表UPDATE ... JOIN写法 - 如果
updated_at有重复值，建议加二级排序（如ORDER BY updated_at DESC, id DESC）避免非确定性结果
MySQL 5.7 的替代写法：用 JOIN 模拟子查询更新
MySQL 5.7 不允许在 UPDATE 中直接引用被更新表的子查询，必须绕过这个限制。常见错误是写成 UPDATE t SET x = (SELECT ... FROM t WHERE ...)，会报错 Error 1093。
正确做法是把子查询包一层派生表（derived table）：
UPDATE target_table t
JOIN (
SELECT user_id, score
FROM (
SELECT user_id, score,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn
FROM source_table
) ranked
WHERE rn = 1
) l ON t.user_id = l.user_id
SET t.latest_score = l.score;
- 外层
JOIN是必须的，不能省略括号里的两层嵌套——第一层ROW_NUMBER()，第二层WHERE rn = 1 - MySQL 5.7 不支持窗口函数？那就换成
LEFT JOIN自关联找最大时间：SELECT s1.user_id, s1.score FROM source_table s1 LEFT JOIN source_table s2 ON s1.user_id = s2.user_id AND s1.updated_at < s2.updated_at WHERE s2.updated_at IS NULL;
- 这个自连接逻辑更通用，但大数据量时性能明显差于窗口函数
UPDATE 前务必加 WHERE 条件限制影响范围
批量更新最怕误触全表。即使你只打算更新匹配到的用户，也要显式写出 WHERE 筛选条件，防止因 JOIN 条件不严导致意外覆盖。
- 例如：加上
AND t.status = 'active'或AND l.score IS NOT NULL，避免把空值或无效状态写进去 - 执行前先用
SELECT验证数据源是否符合预期：SELECT t.user_id, t.latest_score, l.score FROM target_table t JOIN (...) l ON ... - 生产环境强烈建议在事务里操作：
BEGIN; UPDATE ...; SELECT COUNT(*) FROM target_table WHERE ...; ROLLBACK;（验证完再COMMIT）
注意 NULL 值和类型隐式转换带来的静默失败
更新字段类型不一致（比如把字符串塞进整型字段）、目标字段为 NOT NULL 但源数据是 NULL，都可能让部分行更新失败或被截断，而语句本身不报错。
- 检查源字段是否含
NULL：SELECT COUNT(*) FROM source_table WHERE score IS NULL - 确认目标列允许
NULL，或者用COALESCE(l.score, 0)提供默认值 - PostgreSQL 对类型敏感，
text列不能直接赋值给integer；MySQL 可能自动转但会丢精度（如'12.9'→12） - 如果
source_table里某user_id根本没有记录，对应target_table行不会被更新——这通常是预期行为，但得心里有数
updated_at 存的是 UTC，但业务逻辑按本地时区理解“最新”）和重复键冲突（多个“最新”记录并存时，ROW_NUMBER() 的排序依据是否真正唯一）。这些细节不提前对齐，跑出来的结果可能完全不符合业务语义。 
