直接用top 1或limit 1查最大值所在行不保证稳定性，需在order by中追加主键等唯一字段（如order by salary desc, id asc）确保确定性；若需返回所有最大值行，则用子查询where salary = (select max(salary) from t)或窗口函数rank()。
SQL查最大值所在行：TOP 1 和 LIMIT 1 不是万能解法
直接用 SELECT TOP 1 * FROM table ORDER BY col DESC 或 SELECT * FROM table ORDER BY col DESC LIMIT 1 确实能拿到排序后第一行，但**它只保证“排序后的首行”，不保证“唯一最大值所在行”**。如果 col 有重复最大值，结果随机返回其中一行——这在业务上常是错的（比如查“工资最高的人”，但返回了同薪的张三而非李四，且下次可能变）。
当存在多个相同最大值时，如何稳定取一行？
关键不是加 LIMIT 1，而是让排序具备**确定性**。常见做法是在 ORDER BY 中追加主键或唯一字段：
- SQL Server：
SELECT TOP 1 * FROM employees ORDER BY salary DESC, id ASC - MySQL / PostgreSQL：
SELECT * FROM employees ORDER BY salary DESC, id ASC LIMIT 1
这样即使多人薪资相同，也会按 id 升序稳定取最小 ID 的那条。注意：id ASC 不能省略，否则数据库仍可能任意选行。
需要返回所有最大值行（不止一行）怎么办？
LIMIT 1 或 TOP 1 天然只返回一行，此时必须换思路：
- 用子查询先算出最大值：
SELECT * FROM employees WHERE salary = (SELECT MAX(salary) FROM employees) - 或用窗口函数（推荐，性能更可控）：
SELECT * FROM (SELECT *, RANK() OVER (ORDER BY salary DESC) rnk FROM employees) t WHERE rnk = 1
RANK() 会把所有并列最大值都标为 rnk = 1；若只要一个，改用 ROW_NUMBER() 并配合确定性排序（如 ORDER BY salary DESC, id ASC）。
不同数据库对 TOP/LIMIT 的语法和语义差异
写法不统一只是表象，真正影响行为的是**执行计划是否允许隐式去重或优化跳过**：
- SQL Server 的
TOP 1在无ORDER BY时行为未定义，**必须显式排序**，否则结果不可预测 - MySQL 8.0+ 的
LIMIT 1若没ORDER BY，实际返回顺序取决于存储引擎扫描顺序（InnoDB 是聚簇索引顺序），不是“随便一条”而是“第一条物理读到的”，但依然不稳定 - PostgreSQL 的
LIMIT 1同样依赖ORDER BY，否则 planner 可能选任意执行路径，结果不可重现
跨库迁移时，别只改关键字，重点检查 ORDER BY 是否含足够排序字段——这是最容易被忽略、也最常导致线上数据不一致的地方。
