必须在触发器第一行保存@@ROWCOUNT，否则后续语句会覆盖原始DML行数；DECLARE @orig INT = @@ROWCOUNT需置于SET NOCOUNT ON之前；INSTEAD OF触发器中@@ROWCOUNT恒为0，应改用INSERTED/DELETED表统计。

触发器里读@@ROWCOUNT必须抢在第一条语句执行前，否则它早被覆盖了

SQL Server触发器中@@ROWCOUNT为什么总不是原始DML的行数？

因为@@ROWCOUNT是“上一条语句影响的行数”，而触发器一进来，原始UPDATE/INSERT/DELETE已经执行完了——它的值确实存在，但只要你在触发器里写哪怕一行SELECT 1、PRINT 'x'或IF @x > 0，@@ROWCOUNT立刻被重置为那条语句的结果（通常是1或0）。

常见错误现象：IF @@ROWCOUNT = 0 BEGIN ... END写在触发器中间，结果永远进不去——因为前面的变量赋值或条件判断已经改写了它。

• 必须在触发器第一行就保存：例如DECLARE @orig_rows INT = @@ROWCOUNT
• 后续所有逻辑都用@orig_rows，别再碰@@ROWCOUNT
• 如果触发器里还要做INSERT/UPDATE，每次关键操作后需重新存一次，比如DECLARE @log_rows INT = @@ROWCOUNT
• 注释不算语句，但带分号的空语句;会重置@@ROWCOUNT（极少见，但真实存在）

SET NOCOUNT ON会影响@@ROWCOUNT吗？

不影响。SET NOCOUNT只是抑制“X 行受影响”消息返回给客户端，不干扰@@ROWCOUNT的内部更新逻辑。你仍然能用它获取上一条语句的真实影响行数。

但要注意：如果你在触发器开头加了SET NOCOUNT ON，它本身不改变@@ROWCOUNT；可一旦它后面紧跟SELECT或INSERT，那条语句就会覆盖原始值。

• 正确顺序：DECLARE @orig INT = @@ROWCOUNT; SET NOCOUNT ON;
• 错误顺序：SET NOCOUNT ON; DECLARE @orig INT = @@ROWCOUNT; → 此时@@ROWCOUNT已是0（SET语句不返回行数）
• SET NOCOUNT ON对性能有好处，但和@@ROWCOUNT保存是两件事，别混为一谈

为什么AFTER触发器里查不到原始DML的@@ROWCOUNT？

不是“查不到”，是“来不及查”。AFTER触发器的执行时机在原始DML完成之后、事务提交之前，此时@@ROWCOUNT确实还保留着原始值——但前提是触发器体还没执行任何其他语句。

真正的问题在于：很多开发者习惯在触发器里先做日志记录、权限检查或数据校验，这些前置操作直接把@@ROWCOUNT冲掉了。

• AFTER触发器仍可安全使用@@ROWCOUNT，但必须满足“第一行就是保存动作”
• INSTEAD OF触发器不行：原始DML根本没执行，@@ROWCOUNT是0，得靠INSERTED/DELETED临时表统计行数
• 如果业务需要稳定获取原始行数，且触发器逻辑复杂，建议把核心统计逻辑提前到存储过程中，由调用方传入行数参数

最易被忽略的一点：即使你用了DECLARE @r INT = @@ROWCOUNT，如果触发器里有嵌套调用另一个存储过程，而那个过程里也读@@ROWCOUNT并做了判断，它不会影响你的@r——但你的@r只代表触发器入口那一刻的状态，不代表整个事务最终是否成功提交。