MySQL的ROW_COUNT()返回值真正变化的行数，非仅WHERE匹配行；必须紧接UPDATE后调用，中间不可有其他语句；PHP中需禁用MYSQLI_CLIENT_FOUND_ROWS以确保一致性。
MySQL 用 ROW_COUNT() 看“真改动”的行数
MySQL 的 ROW_COUNT() 返回的是值**真正变化了**的行数，不是 WHERE 匹配到的行数。比如 UPDATE users SET name = 'alice' WHERE id = 123，但该行 name 原来就是 'alice'，ROW_COUNT() 就返回 0。
必须注意三点：
- 调用
ROW_COUNT()要紧接在 UPDATE 之后，中间不能有其他语句（包括SELECT），否则值会被覆盖 - 在存储过程或函数里也有效，但它作用于当前会话，不是当前事务
- PHP 中
$conn->affected_rows默认行为和ROW_COUNT()一致；但如果 mysqli 启用了MYSQLI_CLIENT_FOUND_ROWS，它会返回匹配行数而非变更行数，建议显式关闭
SQL Server 和 PostgreSQL 怎么看“匹配但未变”的行
SQL Server 的 @@ROWCOUNT 和 PostgreSQL 的 GET DIAGNOSTICS 或客户端 cursor.rowcount，默认统计的是 WHERE 条件**匹配到的行数**，哪怕新旧值完全一样也算。
例如：
- SQL Server：
UPDATE Users SET status='active' WHERE id=123;→ 即使 status 原值已是 'active'，SELECT @@ROWCOUNT仍返回 1 - PostgreSQL 不支持 SQL 层直接
SELECT行数，得靠客户端：psycopg2 用cursor.rowcount，pgAdmin 执行后看底部状态栏提示 - Oracle 是
SQL%ROWCOUNT，但仅限 PL/SQL 块内可用，普通 SQL 窗口里不能用
程序里拿不到准确行数？先查驱动和执行方式
很多开发者发现 executeUpdate() 返回 0 或 -1，不是数据库没改，而是调用姿势错了。
- Java JDBC 必须用
Statement.executeUpdate()或PreparedStatement.executeUpdate()，它返回 int 类型的受影响行数；execute()不保证返回值有意义 - Python 的 PyMySQL 默认支持
cursor.rowcount，但如果autocommit=False且未提交，某些旧版本会返回 -1 - .NET 的
SqlCommand.ExecuteNonQuery()可靠，但注意：如果 UPDATE 前有SET NOCOUNT ON，它会强制返回 -1 —— 这是 SQL Server 主动屏蔽计数，得关掉
想确认某一行字段是否实质变化？得手动比对 NEW/OLD
数据库原生不提供“字段值是否真的变了”的函数，触发器里尤其容易踩坑。
- MySQL 的
UPDATE('col')只表示 SET 子句里写了该列，不表示值变了；真要判断，得写IF UPDATE('col') AND NEW.col != OLD.col - 注意 NULL 安全：用
NEW.col OLD.col（三等号）替代!=，否则NULL != NULL返回 NULL（即 false） - PostgreSQL 推荐用
OLD.col IS DISTINCT FROM NEW.col，它天然处理 NULL，语义更准确 - 字符串字段慎用
=，要考虑 collation 和尾部空格；必要时加TRIM()或用BINARY强制字节比较
