MySQL中ROW_COUNT()返回UPDATE真正变更的行数，非仅WHERE匹配行；必须紧接UPDATE后调用，中间不可执行其他SQL；客户端通过cursor.rowcount获取，存储过程可用SELECT ROW_COUNT()。
MySQL中用ROW_COUNT()获取UPDATE影响行数
执行UPDATE后，MySQL不默认返回影响数量，必须主动查ROW_COUNT()。它返回上一条DML语句实际变更的行数（不是匹配到的行数，而是真正被修改的行数）。
常见误区是以为WHERE条件匹配多少行就影响多少行——如果新旧值相同，MySQL会跳过更新，ROW_COUNT()就为0。
- 必须在
UPDATE之后**立即**调用ROW_COUNT()，中间不能执行其他SQL语句，否则结果会被覆盖 - 在客户端（如Python、Java）里，通常通过驱动提供的
cursor.rowcount或类似属性获取，本质就是调用了ROW_COUNT() - 存储过程中可直接用
SELECT ROW_COUNT();；交互式命令行里执行完UPDATE后紧跟SELECT ROW_COUNT();
PostgreSQL用RETURNING捕获UPDATE结果集
PostgreSQL没有等价于ROW_COUNT()的会话级函数，但RETURNING子句能直接返回被更新的行，再用COUNT(*)统计更可靠。
它比单纯查影响行数更有价值：你能看到哪些记录变了、变前变后是什么值，尤其适合审计或级联逻辑。
-
UPDATE users SET status = 'active' WHERE id IN (1,2,3) RETURNING id;会返回实际更新成功的id列表 - 如果只想要数量，套一层：
SELECT COUNT(*) FROM (UPDATE ... RETURNING *) AS t;（注意：需在支持CTE或子查询的上下文中使用） -
RETURNING在事务中生效，不会因触发器或约束失败而漏计——只要某行进入RETURNING结果集，就说明它被成功更新了
SQL Server用@@ROWCOUNT获取刚执行的UPDATE行数
和MySQL类似，SQL Server用@@ROWCOUNT返回上一条语句影响的行数，但它统计的是**匹配并尝试更新的行数**，不管新旧值是否真有变化。
这点和MySQL行为不同：即使SET col = col这种无实际变更的操作，@@ROWCOUNT也会返回匹配行数。
- 必须紧接在
UPDATE后读取，任何后续语句（包括PRINT、IF判断）都会重置@@ROWCOUNT - 在存储过程中建议立刻存入变量：
DECLARE @cnt INT = @@ROWCOUNT;，避免被意外覆盖 - 如果
UPDATE带OUTPUT子句，@@ROWCOUNT仍有效，且反映的是最终实际更新的行数（OUTPUT不影响计数逻辑）
跨数据库统一处理的注意事项
不同数据库对“影响行数”的定义不一致：MySQL看值是否真变，SQL Server看是否匹配，PostgreSQL靠RETURNING显式捕获。想写可移植代码，得接受这种差异。
应用层不要假设所有数据库都支持ROW_COUNT()这类函数，也不要依赖UPDATE语句本身返回数字——那只是某些驱动的封装行为，底层协议并不保证。
- 用ORM时（如SQLAlchemy、MyBatis），优先查文档确认其
execute()或update()方法返回值含义，有些返回受影响行数，有些只返回None - 批量更新场景下，如果需要精确知道每一批的变更量，MySQL/SQL Server需分批执行+分别查
ROW_COUNT()/@@ROWCOUNT；PostgreSQL建议用RETURNING配合LIMIT分页 - 触发器或自增字段更新可能干扰计数逻辑，测试时务必在真实表结构和数据上验证
