oracle触发器中sql%rowcount不反映原始dml影响行数，因其仅统计触发器内语句；需用包变量+三级触发器协同统计；sql server须首行保存@@rowcount；postgresql用get diagnostics捕获自执行dml行数；mysql应手动比对old/new字段判断真实变更。
Oracle触发器里用SQL%ROWCOUNT不生效？原因和替代方案
Oracle的语句级触发器（AFTER UPDATE ON table）中，SQL%ROWCOUNT始终返回1或0，不是你期望的“本次UPDATE影响了多少行”。它只反映触发器内部执行的单条语句（比如日志INSERT）的行数，而非外部DML本身。真正想统计原始操作影响的行数，必须绕过这个限制。
常见错误现象：在AFTER UPDATE触发器里直接写DBMS_OUTPUT.PUT_LINE(SQL%ROWCOUNT)，结果总是1——因为触发器体本身算一条语句。
- 必须用包级变量+三级触发器协同：一个
BEFORE触发器初始化计数器，一个FOR EACH ROW触发器每行调用ADD_ONE，一个AFTER触发器读取最终值 - 包定义里
NUMROWS要声明为NUMBER，不能是INTEGER（避免隐式转换失败） -
FOR EACH ROW触发器必须存在，否则ADD_ONE永远不会被调用 - 如果表有大量并发更新，这个包变量是会话级的，不会冲突；但跨会话不可见，也不适合做全局统计
SQL Server触发器内@@ROWCOUNT被覆盖怎么办
SQL Server触发器里，@@ROWCOUNT在触发器开始时就已被原始DML语句设置，但只要你在触发器里执行任何语句（哪怕SELECT 1），它立刻被重写。所以不能指望“进触发器后还能读到原始影响行数”。
正确做法是把原始值从外部传进来，或者在触发器最开头就存住：
- 在触发器第一行立即执行
DECLARE @orig_rows INT = @@ROWCOUNT，后续逻辑全用这个变量 - 不要在
IF、PRINT或SELECT之前读@@ROWCOUNT，哪怕只是注释也算“干扰” - 如果触发器里还要做INSERT/UPDATE，记得在关键步骤后再次保存
@@ROWCOUNT，避免覆盖原始值 - 事务控制语句（
BEGIN TRAN、COMMIT）本身不影响@@ROWCOUNT，但它们后面的语句会
PostgreSQL触发器没法用RETURNING？那就用GET DIAGNOSTICS
PostgreSQL的触发器函数（PL/pgSQL）里，RETURNING子句不能直接用，但可以用GET DIAGNOSTICS捕获上一条DML的影响行数。前提是那条DML必须在同一个函数体内执行——比如你在触发器里动态拼接并执行EXECUTE 'UPDATE ...'，之后立刻GET DIAGNOSTICS就能拿到它影响的行数。
但注意：原始DML（触发这个触发器的那条UPDATE）的行数，触发器函数里无法直接获取。PostgreSQL没提供类似Oracle的SQL%ROWCOUNT机制。
- 只能对触发器内自己执行的DML用
GET DIAGNOSTICS row_count = ROW_COUNT - 变量
row_count必须提前声明为INTEGER类型 -
GET DIAGNOSTICS必须紧跟在目标DML之后，中间不能有其他执行语句 - 如果触发器里用
PERFORM执行查询，它不会改写ROW_COUNT；但SELECT赋值语句会
MySQL触发器里没有ROW_COUNT()可靠？加条件过滤才是关键
MySQL触发器中，ROW_COUNT()返回的是触发器内最后一条DML的影响行数，不是外部语句的。而且即使外部UPDATE的SET子句没改变任何值，只要WHERE匹配了行，ROW_COUNT()也返回匹配数——这和你想知道的“真正变更的行数”不一致。
想严格统计字段值确实变了的行，得在触发器里手动比对：
- 在
BEFORE UPDATE触发器中，用OLD.col != NEW.col判断每行是否真有变化 - 维护一个局部变量（如
@changed_rows := @changed_rows + 1），只在条件成立时累加 - 别依赖
ROW_COUNT()，它在触发器里意义不大；更别在AFTER触发器里查，那时原始语句早已结束 - 如果表有多个字段要校验，用
CONCAT(OLD.f1, OLD.f2) != CONCAT(NEW.f1, NEW.f2)简化写法，但要注意NULL处理
所有数据库的触发器里，“受影响行数”都不是开箱即用的透明值，它要么被触发器自身语句污染，要么需要额外状态管理。最稳的方式永远是：在触发器外先拿到原始行数，再作为参数显式传入；或者干脆放弃在触发器里统计，改由应用层或存储过程统一处理。
