触发器中直接用row_count()或@@rowcount获取影响行数不可靠，因其值仅反映上一条语句结果，需在触发器最顶部立即存入变量；mysql需jdbc加useaffectedrows=true；oracle需避免变量名与列名冲突。
触发器里直接用 ROW_COUNT() 或 @@ROWCOUNT 获取影响行数，基本不可靠——不是函数坏了，而是执行上下文在你没注意时已经变了。
SQL Server 触发器中 @@ROWCOUNT 总是 0？先看语句执行顺序
触发器启动后，@@ROWCOUNT 并不自动指向原始 INSERT/UPDATE/DELETE 的影响行数。它只反映「上一条执行的语句」的结果。而触发器体内的第一行代码（比如 SET NOCOUNT ON、DECLARE @x INT 之后的 SELECT 1、空 IF 分支）会立刻覆盖它。
-
SET NOCOUNT ON本身不改@@ROWCOUNT，但它常被放在开头，紧跟着一条无影响的SELECT或PRINT，后者就把值设成 0 或 1 了 - 写
IF NOT EXISTS (SELECT * FROM INSERTED) RETURN;？这个SELECT会让@@ROWCOUNT变成 1（哪怕INSERTED是空的），后续再读就失真了 - 真正安全的做法：在触发器最顶部、任何其他语句之前，立刻存值：
DECLARE @rc INT = @@ROWCOUNT;或SELECT @rc = @@ROWCOUNT;
MySQL 触发器里 ROW_COUNT() 返回值异常？检查 JDBC 连接参数
MySQL 的 ROW_COUNT() 在触发器内本身没问题，但通过 JDBC 调用存储过程时，返回值常和预期不符——根本原因是客户端默认开启了 CLIENT_FOUND_ROWS 模式。
- 未加
useAffectedRows=true时：UPDATE值未变也返回 1（统计“找到的行”） - 加上
?useAffectedRows=true后：UPDATE值未变返回 0（这才符合“影响行数”的本意） - 连接 URL 示例：
jdbc:mysql://localhost:3306/db?useAffectedRows=true - 注意：该参数只影响 JDBC 层行为，触发器内部直接调用
ROW_COUNT()不受其影响；但如果你在触发器里调用SELECT ROW_COUNT()再返回给 Java，那 Java 端看到的仍是 JDBC 驱动转换后的值
Oracle 触发器中 SQL%ROWCOUNT 为表记录数？变量名撞了列名
这不是 Oracle 的 bug，是 PL/SQL 作用域规则导致的静默覆盖。当触发器里声明的变量名和表字段名相同时，SQL%ROWCOUNT 会被解析成那个变量（如果它恰好是数字类型），而不是系统隐式游标属性。
- 例如：
DECLARE my_table NUMBER; BEGIN ... DBMS_OUTPUT.PUT_LINE(SQL%ROWCOUNT); END;—— 这里SQL%ROWCOUNT实际输出的是my_table变量的当前值 - 解决方法极简单：重命名所有可能与表名、列名冲突的局部变量，比如改成
v_my_table_cnt - 验证方式：在触发器开头加
DBMS_OUTPUT.PUT_LINE('before: ' || SQL%ROWCOUNT);，确保它出现在任何DECLARE变量赋值之前
别依赖 ROW_COUNT() 判断业务逻辑分支
所有数据库中，ROW_COUNT() 类函数都只是「上一条语句副作用」的快照，不是触发动作本身的权威代理。更稳的方式永远是查 INSERTED/DELETED 表或对应临时结构：
- SQL Server：
IF (SELECT COUNT(*) FROM INSERTED) > 0比IF @@ROWCOUNT > 0更可靠 - MySQL：
SELECT COUNT(*) INTO v_cnt FROM information_schema.tables WHERE ...不适用；应直接在触发器中对新旧值做条件判断，而非依赖函数返回 - Oracle：
:NEW.column_name IS NOT NULL或:OLD.column_name != :NEW.column_name才是判断是否真修改的依据
真正容易被忽略的点是：这些函数值在语句执行完那一刻就固化了，之后任何变量赋值、日志打印、条件跳转都会刷新它——你得在它被污染前，用一次赋值操作把它钉死在变量里。
