sql server 中必须用 top 1 而非 limit，且必须搭配 order by 否则结果不可靠；替代方案包括 offset-fetch（需 order by）、row_number()（跨版本兼容但需嵌套）、相关子查询（全数据库兼容）；first_value 仅返回单列值，不等价于取首行整记录。
SQL Server 用 TOP 1 替代 LIMIT
SQL Server 原生不支持 LIMIT，直接写 LIMIT 1 会报错 Incorrect syntax near 'LIMIT'。必须用 TOP 1，且 TOP 必须紧跟 SELECT 后面，不能放在末尾。
关键点在于：没有 ORDER BY 的 TOP 1 返回任意一行，结果不可靠。实际使用时必须配 ORDER BY 明确排序依据，例如按时间戳取最新记录：
SELECT TOP 1 * FROM logs ORDER BY created_at DESC
常见错误包括：
- 漏写
ORDER BY，误以为“第一条”是插入顺序——SQL 标准不保证物理顺序 - 在子查询里用
TOP 1却没加ORDER BY，导致外层关联结果随机波动 - SQL Server 2012+ 虽支持
OFFSET-FETCH，但FETCH FIRST 1 ROWS ONLY仍需搭配ORDER BY，否则语法报错
MySQL 8.0+ 用 ROW_NUMBER() 窗口函数
当不能用 LIMIT（比如在视图定义、CTE 或不允许截断结果的上下文中），ROW_NUMBER() 是更可控的替代方案。
它给每行分配唯一序号，再用外层 WHERE rn = 1 筛选：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY updated_at DESC) AS rn FROM products ) t WHERE rn = 1
注意：
-
ROW_NUMBER()在 MySQL 8.0+ 和 SQL Server 2005+ 都可用，但 Oracle 和旧版 MySQL 不适用 - 如果排序字段有重复值（如多个记录
updated_at相同），必须加次级排序字段（如id）保证序号稳定，否则每次执行可能选不同行 - 相比
LIMIT，窗口函数多一次嵌套，小数据量无感，大数据集要注意执行计划是否走索引
通用兼容写法：相关子查询 + MIN(id)
适用于所有主流数据库（MySQL 5.7、SQL Server、PostgreSQL、Oracle），不依赖高级语法，适合需要跨库迁移或老版本环境。
核心思路：先找出满足条件的最小主键（或时间戳），再关联回原表取整行：
SELECT * FROM orders o1 WHERE o1.id = ( SELECT MIN(o2.id) FROM orders o2 WHERE o2.status = 'pending' )
这个写法的问题很实在：
- 只适用于有单调递增主键或能代表“先后”的字段（如
created_at）；若用MIN(created_at)，得确保该字段非空且唯一性足够 - 若条件无匹配行，整个查询返回空结果集（不是
NULL行），和TOP 1/LIMIT行为一致 - 性能取决于
id或排序字段是否有索引；没索引时子查询会全表扫描
别踩 FIRST_VALUE 的坑
看到“第一条”，容易直觉想到窗口函数 FIRST_VALUE(value)，但它不等于“取第一行整条记录”。
FIRST_VALUE 只返回窗口内指定列的值，且默认包含所有行（含 NULL），不会自动跳过空值或限制行数：
SELECT FIRST_VALUE(name) OVER (ORDER BY id) AS first_name FROM users
这句哪怕 name 第一行是 NULL，也会返回 NULL，而不是跳到下一个非空值。真要“第一条非空”，得手动构造 ORDER BY CASE WHEN name IS NOT NULL THEN 0 ELSE 1 END, id，再套 FIRST_VALUE ——但此时不如直接用 ROW_NUMBER() 或子查询清晰。
最常被忽略的一点：所谓“第一条”，本质是你定义的排序逻辑，不是数据库内置概念。没显式 ORDER BY，任何“第一”都不可信。
