不同数据库分页语法互不兼容：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
