sql server中top后不能直接跟变量，需用offset-fetch或动态sql；mysql和postgresql的limit语法及分页性能差异显著，深分页应改用游标分页。
SQL Server 用 SELECT TOP 取前 N 行，但不能写 TOP 后直接跟变量
SQL Server 不支持 SELECT TOP @n * FROM table 这种写法，会报错 Incorrect syntax near '@n'。必须用动态 SQL 或改用 OFFSET-FETCH（SQL Server 2012+）。
实操建议：
- 固定数量用
SELECT TOP 10 *最简单，性能也好 - 需要参数化时，优先选
OFFSET 0 ROWS FETCH NEXT @n ROWS ONLY，语法标准且可参数化 - 如果必须用
TOP+ 变量，得拼字符串再EXEC sp_executesql，但要注意 SQL 注入风险，尤其变量来自用户输入
MySQL 和 PostgreSQL 用 LIMIT，但位置和语义有区别
MySQL 的 LIMIT 5 等价于 LIMIT 0, 5，而 PostgreSQL 要求显式写成 LIMIT 5 OFFSET 0；不写 OFFSET 时两者都默认从第 0 行开始，但 MySQL 允许 LIMIT 5, 10（跳过 5 行取 10 行），PostgreSQL 必须拆成 LIMIT 10 OFFSET 5。
实操建议：
- 跨数据库移植时，别用 MySQL 风格的
LIMIT 5,10，统一用LIMIT 10 OFFSET 5更安全 -
LIMIT在没有ORDER BY时结果不稳定，特别是并发写入频繁的表——同一语句多次执行可能返回不同行 - MySQL 8.0+ 支持
LIMIT后加变量（如LIMIT ?），但需预处理语句，普通查询仍不认变量
分页查第 N 页数据，LIMIT/OFFSET 深度翻页性能差
当 OFFSET 很大（比如 OFFSET 100000），数据库仍要扫描前 10 万行再丢弃，响应明显变慢，不是“跳过去”而是“数过去”。
实操建议：
- 避免
LIMIT 20 OFFSET 200000这类深分页，改用基于游标的分页（cursor-based pagination）：用上一页最后一条记录的id或时间戳做条件，例如WHERE created_at - 如果必须用偏移量，给排序字段加索引，否则
ORDER BY+OFFSET会触发 filesort，更慢 - 某些场景下，前端可限制最大页码（如只允许查前 1000 页），后端直接拒绝超限请求，比硬扛更实际
SQLite 的 LIMIT 支持完整，但不支持 OFFSET 单独出现
SQLite 允许 LIMIT 5 OFFSET 10，但不允许只写 OFFSET 10（会报错 near "OFFSET": syntax error）。另外，它不支持 TOP，也不支持 FETCH FIRST（除非启用 compat 模式）。
实操建议：
- SQLite 分页必须写全
LIMIT … OFFSET …，哪怕只想跳过几行取全部，也得估算个足够大的LIMIT值（如LIMIT 9223372036854775807，即 SQLite 的最大整数） - 在嵌套查询中，
LIMIT作用于最外层，内层子查询不能单独用LIMIT（除非用 CTE 或派生表包装） - Android 或 iOS App 里用 SQLite 时，注意旧版本（如 Android 4.x 自带 SQLite 3.7.x）不支持
ORDER BY+LIMIT在子查询中，得把排序提到外层
有些数据库对 LIMIT / TOP 的解析逻辑藏得很深，比如是否自动去重、是否影响执行计划里的行数预估——这些不会报错，但会让分页结果或性能表现和预期不一致。
