sql server存储过程中安全传入offset和fetch参数必须用参数化查询，禁用字符串拼接；@page_size需校验≤100，@page_index≥1，offset计算为(@page_index-1)*@page_size，且须有order by、先offset后fetch、fetch后跟next…rows only。
SQL Server 存储过程中怎么安全传入 OFFSET 和 FETCH 参数
不能拼字符串，必须用参数化查询，否则必然 SQL 注入。哪怕只是内部系统，也别心存侥幸。
实操建议：
-
@page_size必须做上限校验，比如IF @page_size > 100 THROW 50000, 'Page size too large', 1，防恶意拉取全表 -
@page_index必须 ≥ 1，计算OFFSET时用(@page_index - 1) * @page_size，避免负数或整数溢出（尤其当@page_index超过 2147483647 /@page_size时） - 所有参数都声明为
INT或BIGINT，别用VARCHAR接数字再转——类型不匹配会隐式转换失败或执行计划失效
为什么总是报 “Invalid usage of the option NEXT in the FETCH statement”
这是 SQL Server 对语法错误的精准提示，不是环境问题，也不是版本不对（只要 ≥ 2012 就支持），99% 是写法不合规。
常见原因：
- 漏了
ORDER BY——OFFSET和FETCH强制要求排序，没它直接报错 -
FETCH前没写OFFSET，或者顺序颠倒（必须先OFFSET后FETCH） - 写了
FETCH @size ROWS—— 变量不被允许，必须是字面量或参数名，且后面必须跟NEXT ... ROWS ONLY，少一个词（比如漏ONLY）都报错 - 动态 SQL 中最终生成的语句含多余空格或换行，导致解析器误判关键词位置（比如
FETCH\nNEXT被断成两行）
OFFSET FETCH 在大偏移量下越来越慢，是不是写错了
不是写错，是设计如此。OFFSET 越大，引擎越要“数着跳过”前面所有行，本质是 B+ 树线性遍历，和索引深度正相关。
哪怕 ORDER BY created_at 字段有索引，当 OFFSET 达到 10 万以上，响应延迟也会明显上升——这不是 bug，是物理限制。
能做的只有：
- 强制加索引：确保
ORDER BY列（如created_at、id）上有复合索引，且顺序与查询一致 - 拒绝超深分页：在存储过程开头加判断，比如
IF @page_index > 1000 THROW 50000, 'Page index out of range', 1 - 改用游标分页：记录上一页最后一条的
(created_at, id)，下一页查WHERE (created_at, id)
MySQL 8.0+ 存储过程中用 OFFSET FETCH 还是 LIMIT
MySQL 不支持 OFFSET FETCH 语法，只认 LIMIT offset, size 或 LIMIT size OFFSET offset。强行写 FETCH 会报语法错误。
所以 MySQL 存储过程里必须用 LIMIT，但要注意：
-
LIMIT后不能直接跟变量（旧版 MySQL 不支持），得用动态 SQL +PREPARE/EXECUTE -
LIMIT 10, 20表示跳过 10 行取 20 行，和 SQL Server 的OFFSET 10 ROWS FETCH NEXT 20 ROWS ONLY等价，但参数顺序相反 - MySQL 8.0.12+ 才开始支持标准
OFFSET ... FETCH，但实际极少有人用——生态和习惯已固化在LIMIT上
真正卡住性能的，往往不是语法写对没写对，而是忘了 ORDER BY 字段有没有索引，或者让前端传了个 @page_index = 10000 还照单全收。分页不是功能点，是数据访问契约，得从存储过程第一行就守住边界。
