SQL Server中用@@ROWCOUNT获取UPDATE影响行数，需紧跟在UPDATE后立即读取，否则值会被后续语句覆盖；它返回实际被修改的行数，且受触发器内语句干扰。
SQL Server里怎么拿到UPDATE影响了多少行
SQL Server用@@ROWCOUNT是最直接的方式，它在每个语句执行后自动更新，保存上一条DML（INSERT/UPDATE/DELETE）实际影响的行数。关键点是：它必须紧跟在目标语句后面读取，中间不能插任何其他语句（哪怕只是PRINT或变量赋值），否则值会被覆盖。
常见错误现象：SELECT @@ROWCOUNT放在UPDATE之后隔了一行，结果返回0；或者在存储过程中UPDATE后调用了另一个查询，再查@@ROWCOUNT就变成那个查询的影响行数了。
- UPDATE后立刻用
SELECT @@ROWCOUNT或SET @rows = @@ROWCOUNT - 如果UPDATE带WHERE，
@@ROWCOUNT只统计真正被修改的行（即使SET子句没变数据，只要行被扫描并满足WHERE，也算入） - 注意触发器里的语句也会改写
@@ROWCOUNT，如果UPDATE触发了AFTER触发器，且触发器内有SELECT，那外部读@@ROWCOUNT可能得到触发器里最后一条语句的结果
MySQL里为什么不能用@@ROWCOUNT
MySQL确实有ROW_COUNT()函数，但它和SQL Server的@@ROWCOUNT行为不一致：在UPDATE中，它返回的是“匹配到的行数”，而不是“实际发生变更的行数”。也就是说，哪怕SET子句把字段设成和原来一样的值，只要WHERE命中了，ROW_COUNT()就会计1。
想严格统计“真正被改掉的行”，得加条件判断：
- 用
UPDATE ... SET col = ? WHERE col != ? AND ...，把变更条件显式写进WHERE - 或者用
SELECT COUNT(*) FROM ... WHERE ... AND (old_value != new_value)先估算，再UPDATE（适合小批量） - MySQL 8.0+ 可配合
INFORMATION_SCHEMA.INNODB_METRICS查变更量，但开销大，一般不用
PostgreSQL里没有内置Rowcount变量怎么办
PostgreSQL不提供类似@@ROWCOUNT的会话级变量，但提供了RETURNING子句——这是更可控的方式。它能返回UPDATE实际修改的每一行的指定字段，再用COUNT(*)包一层就能拿到精确行数。
示例：UPDATE users SET status = 'active' WHERE id IN (1,2,3) RETURNING id;，然后在应用层对结果集计数；或者嵌套成：SELECT COUNT(*) FROM (UPDATE users SET status = 'active' WHERE id IN (1,2,3) RETURNING 1) AS t;
-
RETURNING还能帮你确认哪些具体行被改了，比单纯一个数字更有调试价值 - 如果UPDATE没匹配到任何行，
RETURNING返回空结果集，COUNT就是0 - 注意：不能在函数或存储过程里用
RETURNING直接赋值给变量（除非用PL/pgSQL的GET DIAGNOSTICS）
跨数据库写法要注意什么
没有银弹。不同数据库对“影响行数”的定义本身就不同：SQL Server看是否进入UPDATE流程，MySQL看是否匹配WHERE，PostgreSQL看是否真正执行了赋值动作（哪怕值相同也计）。所以别指望一套代码到处跑。
- ORM如Django ORM、SQLAlchemy默认不暴露底层行数，得用
execute()+ 原生语句再手动查 - 批量UPDATE时，有些数据库（如Oracle）用
BULK COLLECT才能高效拿到每批的SQL%ROWCOUNT，单条UPDATE的ROWCOUNT在循环里会被覆盖 - 日志或监控里记录行数时，务必注明是“匹配行数”还是“变更行数”，否则排查数据不一致时容易误判
最麻烦的其实是业务逻辑依赖这个数字做分支判断——比如“如果更新0行就插入”，这时候光靠ROWCOUNT不够，得结合SELECT检查存在性，不然竞态条件下可能出错。
