用 row_number() 替代子查询最稳妥，因其按指定排序生成唯一序号并筛选序号为1的行，支持多列排序、去重及主键保留，避免重复最大值导致多行返回或优先级失控问题。
用 ROW_NUMBER() 替代子查询拿最大值行最稳
直接用子查询找“最大值对应整行”容易错，尤其当有重复最大值或需要关联主键时。ROW_NUMBER() 是更可控的解法，它按指定排序给每行打唯一序号，再筛序号为 1 的行，天然支持多列排序、去重逻辑和主键保留。
常见错误现象：SELECT * FROM t WHERE score = (SELECT MAX(score) FROM t) 看似简洁，但只要有多人并列最高分，就会返回多行——而你真正想要的可能只是其中一条（比如最新插入的那条）；更糟的是，如果要同时取 user_id 和 created_at，这个写法根本没法控制优先级。
- 必须显式写
ORDER BY，否则ROW_NUMBER()行为不可预测（不同数据库默认策略不同） - 排序字段里建议包含主键（如
ORDER BY score DESC, id DESC），避免因相同分数导致窗口函数分配顺序不一致 - MySQL 8.0+、PostgreSQL、SQL Server 都支持；SQLite 3.25+ 也支持，但旧版 SQLite 只能退化用相关子查询
SELECT id, name, score
FROM (
SELECT id, name, score,
ROW_NUMBER() OVER (ORDER BY score DESC, id DESC) AS rn
FROM users
) ranked
WHERE rn = 1;
为什么不能只靠 MAX() + 关联子查询
MAX() 只返回标量值，它本身不携带任何行上下文。想靠它反查原表某一行，就得额外做一次 JOIN 或相关子查询，性能差、逻辑绕、还容易漏数据。
使用场景：比如日志表中查“每个用户最后一条操作记录”，有人会写：SELECT * FROM logs l1 WHERE l1.created_at = (SELECT MAX(l2.created_at) FROM logs l2 WHERE l2.user_id = l1.user_id) —— 这在小表上勉强能跑，但一旦 user_id 和 created_at 缺少联合索引，执行计划大概率是嵌套循环 + 全表扫描。
- 相关子查询对每一行都触发一次内层查询，复杂度接近 O(n²)
- 即使加了索引，优化器也不总能正确识别“最大时间戳 + 分组”的意图，常退化为临时表或文件排序
- 若存在毫秒级时间戳重复，仍可能返回多行，且无法控制取哪一条
用 JOIN + 聚合结果反查的坑
有人试图先聚合出最大值及对应主键：SELECT user_id, MAX(created_at) FROM logs GROUP BY user_id，再用这个结果 JOIN 原表。问题在于：聚合结果里没有原表的其他字段（比如 action 或 ip），JOIN 后还得处理“多个同时间戳记录怎么选”的问题。
典型错误现象：JOIN 后发现行数暴涨，因为一个 user_id + MAX(created_at) 对应了多条原始记录，又没加 DISTINCT 或限制逻辑，最终结果既不准又慢。
- 除非业务明确允许任意一条，否则这种写法本质是放弃控制权
- 多数数据库不支持在聚合查询中直接
SELECT *，必须显式列出非聚合字段，否则报错（如 MySQL 5.7+ 的sql_mode=ONLY_FULL_GROUP_BY） - 即使关掉严格模式，结果也是随机选取，不同执行可能返回不同行，测试难复现
MySQL 5.7 以下或简单场景用 LIMIT 1 加 ORDER BY
如果只查全局最大值对应的一行（不要分组），且数据库版本较老，LIMIT 1 是最直白的选择。它不依赖窗口函数，兼容性好，语义清晰。
注意点全在 ORDER BY：必须覆盖所有可能影响排序稳定性的字段。比如只写 ORDER BY score DESC，遇到并列最高分时，数据库返回哪条完全由存储顺序决定，下次执行可能变。
- 务必补上主键或时间戳字段二次排序，例如：
ORDER BY score DESC, id DESC -
LIMIT 1不适用于分组场景（如“每个部门最高薪员工”），那是窗口函数或相关子查询的职责 - PostgreSQL 中可用
LIMIT 1，但注意它不等价于FETCH FIRST 1 ROW ONLY（后者在某些 CTE 场景下行为更标准）
SELECT id, name, score FROM users ORDER BY score DESC, id DESC LIMIT 1;
实际用的时候，别光盯着“怎么写出最大值那行”，得想清楚：你要的是唯一确定的一行，还是可接受任意一行？有没有分组需求？数据库版本卡在哪？这些决定了该用窗口函数、LIMIT，还是干脆重构查询结构。最容易被忽略的是排序字段的完备性——少一个主键，就可能让结果在不同环境里来回漂移。
