不同数据库分页语法互不兼容：sql server用top n或offset-fetch，mysql/postgresql用limit，sqlite仅支持limit；offset-fetch需配合order by且性能差，深分页应改用游标分页。

SQL Server用TOP，MySQL/PostgreSQL用LIMIT

不同数据库对“取前N条”的实现完全不同，不能混用。SQL Server必须写TOP N在SELECT关键字后；MySQL和PostgreSQL则把LIMIT N放在语句末尾。写错位置或换错关键词会直接报错。

常见错误现象：SELECT * FROM users LIMIT 10 在 SQL Server 中报错 Incorrect syntax near 'LIMIT'；反过来，SELECT TOP 10 * FROM users 在 MySQL 8.0 以前会报错 Unknown column 'TOP' in field list（误把TOP当字段名）。

• TOP支持TOP N PERCENT，比如TOP 10 PERCENT——LIMIT没有等价语法，得靠子查询或窗口函数模拟
• LIMIT可接两个参数：LIMIT offset, count（如LIMIT 20, 10跳过前20条取10条）；TOP本身不支持偏移，需配合OFFSET-FETCH（SQL Server 2012+）
• SQLite只认LIMIT，且不支持OFFSET单独写，必须成对出现

OFFSET-FETCH是SQL Server里替代LIMIT偏移的唯一标准写法

想实现“第2页、每页10条”，SQL Server不能用TOP硬凑，必须用OFFSET-FETCH。它不是可选语法糖，而是ANSI SQL标准的一部分，在较新版本中才稳定支持。

使用场景：分页查询、后台管理列表、API数据分页返回。

• 必须搭配ORDER BY，否则报错 The OFFSET clause is missing in the ORDER BY clause
• 写法固定为：ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY（跳过20行，取10行）
• FETCH NEXT不能简写为FETCH，也不能漏掉ONLY
• 性能注意：大偏移量（如OFFSET 100000）会导致全表扫描，比LIMIT在MySQL中更重，建议用游标分页替代

PostgreSQL的LIMIT和OFFSET可以分开写，但慎用于深分页

PostgreSQL允许LIMIT和OFFSET独立存在，比如只写LIMIT 5不加OFFSET完全合法；但实际分页时，OFFSET越大，性能越差——因为它仍要数完前面所有行。

常见错误现象：页面卡顿、查询超时，尤其在千万级表上OFFSET 100000可能耗时数秒。

• 避免用OFFSET做“跳转到第N页”，改用基于游标的分页（如记录上一页最后的id，用WHERE id > last_id LIMIT 10）
• LIMIT ALL等价于不限制，但不如直接删掉LIMIT清晰
• 如果必须用OFFSET，确保ORDER BY字段有索引，否则性能雪崩

跨数据库写分页逻辑时，别幻想一条SQL通吃

没有银弹。ORM（如Django ORM、SQLAlchemy）或查询构建器（Knex、MyBatis）能屏蔽差异，但手写SQL时，必须按目标数据库选语法。硬套会失败，临时拼接又容易引入SQL注入风险。

容易被忽略的地方：开发环境用SQLite（LIMIT），上线切到SQL Server（TOP或OFFSET-FETCH），测试覆盖不到就炸。

• CI流程中应至少跑两种方言的分页SQL，避免上线才发现语法错误
• 如果用JDBC，Statement.setMaxRows()能强制限制结果集大小，但它是客户端行为，不减少网络传输和数据库计算开销
• PostgreSQL 13+ 支持LIMIT带参数（LIMIT $1），但SQL Server的TOP后面不能直接跟参数占位符，必须用动态SQL或OFFSET-FETCH