FETCH FIRST 是标准 SQL 语法，PostgreSQL（9.5+）、Oracle（12c R2+）、SQL Server（2012+）、DB2、Snowflake、Trino 支持；MySQL（8.0.22+）和 SQLite（3.35.0+）较晚支持，旧版本需用 LIMIT 或 ROWNUM 替代。
FETCH FIRST 是标准 SQL 里最可靠、语义最清晰的分页取前 N 行的方式，但不是所有数据库都支持，且行为细节容易踩坑。
哪些数据库支持 FETCH FIRST？
PostgreSQL（9.5+）、DB2、Oracle（12c R2+）、SQL Server（2012+）、Snowflake、Trino 都支持；MySQL 和 SQLite 原生不支持（MySQL 8.0+ 可用 LIMIT 替代，SQLite 3.35.0+ 才开始支持 FETCH FIRST）。
实际写之前先确认版本：SELECT version();（PostgreSQL）SELECT @@VERSION;（SQL Server）SELECT * FROM V$VERSION;（Oracle）
- 别在 MySQL 5.7 或旧版 SQLite 上硬写
FETCH FIRST，会直接报错SQL Error: ORA-00933或类似语法错误 - PostgreSQL 对
FETCH FIRST解析较宽松，允许省略ROWS（如FETCH FIRST 10 ROWS ONLY可简写为FETCH FIRST 10 ONLY），但其他数据库通常要求显式写ROWS
FETCH FIRST 和 LIMIT 的关键区别
LIMIT 是 PostgreSQL/MySQL 的扩展语法，非标准；FETCH FIRST 是 ISO/IEC 9075 标准语法，语义更严谨——它必须跟在 ORDER BY 后面才合法（否则部分数据库如 Oracle 会报 ORA-00978）。
-
ORDER BY不是可选的：没有排序就取“前 N 行”，结果不可预测；标准 SQL 明确要求FETCH FIRST必须配合ORDER BY -
LIMIT 10在 PostgreSQL 中可独立使用，但等价于FETCH FIRST 10 ROWS ONLY；而FETCH FIRST 10 ROWS WITH TIES是LIMIT没有的能力（返回并列第 10 名的所有行） - 性能上无本质差异，但某些优化器对
FETCH FIRST更友好（例如 Oracle 的ROWNUM伪列方式已被标记为过时）
常见写法与易错点
正确写法示例（以用户表按注册时间取最新 5 条为例）：
SELECT id, name, created_at FROM users ORDER BY created_at DESC FETCH FIRST 5 ROWS ONLY;
错误写法及后果：
- 漏掉
ORDER BY→ Oracle 报ORA-00978，SQL Server 报Msg 10727 - 写成
FETCH FIRST 5（缺ROWS ONLY）→ PostgreSQL 允许，但 DB2 和 Oracle 会报语法错误 - 和
OFFSET混用顺序错误：必须是ORDER BY ... OFFSET ... FETCH FIRST ...，反过来（FETCH FIRST在OFFSET前）会报错 - 用
WITH TIES但没定义排序键的唯一性 → 可能返回远超预期的行数（比如 5 行变成 12 行），调试时容易误判逻辑
兼容旧数据库的替代方案
如果目标环境不确定是否支持 FETCH FIRST，不要靠运行时 try-catch 切换语法——应由应用层或构建时根据数据库类型生成对应 SQL。
- PostgreSQL / SQL Server：优先用
FETCH FIRST n ROWS ONLY - MySQL：用
LIMIT n（注意它不强制要求ORDER BY，但业务上仍应加上） - Oracle ROWNUM <= n 嵌套子查询，且必须把
ORDER BY放内层，否则排序失效 - SQLite LIMIT n，别尝试
FETCH FIRST
真正麻烦的是跨多数据库的 ORM 场景——像 Hibernate 的 setFirstResult()/setMaxResults() 底层会自动适配，但手写原生 SQL 时，排序字段是否含 NULL、索引覆盖是否完整，这些细节比语法选择更容易导致性能崩塌。
