SET ROWCOUNT 限制后续 DML 行数但对 SELECT 无效（SQL Server 2012+ 忽略），是会话级设置，需显式 SET ROWCOUNT 0 恢复；官方已标记为将弃用，推荐用 TOP 或 OFFSET/FETCH 替代。
SQL Server 中 SET ROWCOUNT 的实际行为与失效场景
SET ROWCOUNT 在 SQL Server 里确实能限制后续 INSERT、UPDATE、DELETE 语句影响的行数，但它对 SELECT 无效——这是最常被误用的点。很多人以为写 SET ROWCOUNT 10; SELECT * FROM t; 就能只取前 10 行，但实际它完全不生效（SQL Server 2012+ 会忽略该设置对 SELECT 的作用）。真正起效的是 TOP 或 OFFSET/FETCH。
使用时要注意：SET ROWCOUNT 是会话级开关，一旦设置就持续生效，直到被重置为 0 或连接断开。没重置就可能意外截断后续其他 DML 操作。
-
SET ROWCOUNT 5后执行DELETE FROM orders WHERE status = 'pending'，最多删 5 行，哪怕有 100 行匹配 - 若之后忘了
SET ROWCOUNT 0，下一条UPDATE也可能只改前几行，引发数据不一致 - 在存储过程中使用，必须显式恢复（建议开头存原值，结尾还原）
替代 ROWCOUNT 的标准分页写法（SQL Server 2012+）
要用“限制查询返回行数”，直接用 OFFSET + FETCH 最可靠，语义清晰且符合 ANSI 标准：
SELECT id, name FROM users ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
注意两点：必须带 ORDER BY，否则报错；OFFSET 值为 0 才表示从头开始（不是省略）。
- 性能上，大偏移量（如
OFFSET 1000000）仍需跳过前面所有行，不如用键集分页（WHERE id > @last_id）高效 -
TOP更轻量，适合简单取前 N 行：SELECT TOP 100 * FROM logs ORDER BY ts DESC -
TOP不支持动态行数（除非拼字符串或用EXEC），而OFFSET/FETCH可用变量
MySQL 和 PostgreSQL 怎么对应实现？
不同数据库没有 ROWCOUNT 这种会话级限制机制，但都有等效语法：
- MySQL 用
LIMIT：SELECT * FROM events LIMIT 50或LIMIT 100, 20（跳过 100 行取 20 行） - PostgreSQL 同样用
LIMIT+OFFSET：SELECT * FROM audit LIMIT 30 OFFSET 60 - 三者都要求排序明确才能保证分页结果稳定，否则
LIMIT或OFFSET返回的行可能重复或遗漏
特别提醒：MySQL 8.0+ 支持 ROW_NUMBER() 窗口函数，但仅用于计算序号，不能替代 LIMIT 控制输出量。
为什么不该依赖 ROWCOUNT 做业务逻辑控制？
它本质是调试/运维工具，不是编程接口。SQL Server 官方文档已明确标注 SET ROWCOUNT “will be deprecated in a future version”，未来版本可能彻底移除。
- 跨数据库移植性为零（MySQL/PostgreSQL/Oracle 都不认这个）
- 无法在视图、内联表值函数中使用
- 与查询计划缓存交互复杂，可能导致同一语句因
ROWCOUNT设置不同而生成不同执行计划 - 如果业务需要“最多处理 N 行”，应在应用层控制循环次数，或用
TOP/LIMIT显式声明意图
真正容易被忽略的是：即使你在存储过程里谨慎用了 SET ROWCOUNT 并及时重置，只要过程中调用了其他含 DML 的存储过程，那些过程内部是否也遵守了同样的重置逻辑？这种隐式依赖很难审计。
