用ROW_NUMBER()配合OVER(PARTITION BY...ORDER BY...)取每组首行最稳妥，能保留整行数据且避免并列不确定性；须加确定性排序（如ORDER BY score DESC, id ASC），不可在WHERE中直接引用窗口别名。
用 ROW_NUMBER() 给每组排序后取第一条最稳
直接在窗口函数里按分组和排序规则编号，再外层筛 rn = 1，比 GROUP BY + MAX() 联查或子查询更直观、更不容易漏字段。关键是它能保留整行原始数据，不是只拿个最大值回来。
常见错误是写成 ORDER BY value DESC 却没处理并列情况——比如同组两个记录 score = 95，ROW_NUMBER() 会任意给 1 和 2，导致结果不固定。这时候得加确定性排序，比如补上主键：ORDER BY score DESC, id ASC。
-
ROW_NUMBER()必须配合OVER (PARTITION BY ... ORDER BY ...)，少一个括号或关键字就报错 - 别在
WHERE里直接引用窗口函数别名（如WHERE rn = 1），必须套一层子查询或 CTE - MySQL 8.0+、PostgreSQL、SQL Server 都支持；SQLite 3.25+ 也行，但旧版不行
GROUP BY + 自关联容易漏数据或性能翻车
有人用 JOIN 或子查询先算出每组最大值，再连回原表匹配，逻辑看似清楚，实际一碰重复值或 NULL 就出问题。比如某组最大值是 NULL，= 判断直接失效；或者多个记录共享最大值，只想要一条却返回多条。
性能上，如果原表没建好索引，这种写法常触发全表扫描两次：一次找最大值，一次回查。而 ROW_NUMBER() 在有合适索引时，通常只需一次扫描。
- 用
MAX()聚合后JOIN，必须确保连接条件能唯一命中——否则得加SELECT DISTINCT或改用IN+ 子查询 -
WHERE value = (SELECT MAX(value) FROM t2 WHERE t2.group_id = t1.group_id)这种写法在 MySQL 5.7 或某些场景下可能不走索引 - PostgreSQL 对这类相关子查询优化较好，但 SQL Server 容易生成低效执行计划
MySQL 5.7 没窗口函数？用变量模拟要小心顺序
老版本 MySQL 只能靠用户变量，但官方早就不推荐了——因为执行顺序不保证，尤其加了 ORDER BY 或涉及连接时，变量赋值可能错乱，结果时对时错。
如果非用不可，必须强制用 ORDER BY 控制顺序，并在 SELECT 里把变量更新和输出写在同一行：
SELECT id, group_id, value
FROM (
SELECT id, group_id, value,
@rn := IF(@prev = group_id, @rn + 1, 1) AS rn,
@prev := group_id
FROM t, (SELECT @rn := 0, @prev := '') AS _
ORDER BY group_id, value DESC, id
) AS ranked
WHERE rn = 1;
-
ORDER BY必须包含分组字段和排序字段，缺一不可 - 变量初始化不能放在同一个 SELECT 里，得用子查询或
SET预设 - 一旦加了
LIMIT或涉及派生表嵌套，变量行为更难预测
取“每组最大值记录”不等于“取最大值”
这是最容易混淆的点：你要的是完整记录（比如用户 ID、时间、状态全都要），不是只要那个最大数字。用 GROUP BY 直接选 MAX(value) 再加其他字段，MySQL 5.7 默认允许但值是随机的，PostgreSQL 和新版本 MySQL 会直接报错 ERROR 1055。
真正安全的做法只有两种：用窗口函数，或者用 GROUP BY + JOIN 回查（但得处理好重复和 NULL）。别指望数据库替你猜哪一行对应最大值。
复杂点在于业务定义——“最大”是按时间？分数？还是字符串字典序？不同字段类型影响 ORDER BY 行为，比如 TEXT 字段没索引时排序代价很高；日期字段要注意时区和精度。这些细节不提前想清楚，查出来数据对不上，第一反应往往是 SQL 写错了，其实可能是语义理解偏了。
