row_count() 在update用相同值更新、sql_safe_updates=1被拒绝、触发器内dml、连接池复用连接等情况下不可靠；它仅反映最外层dml实际变更行数，不等于匹配行数，且受连接隔离影响。
ROW_COUNT() 返回值在什么情况下不可靠？
ROW_COUNT() 的返回值只反映最近一次 DML（INSERT、UPDATE、DELETE）语句实际变更的行数，**不等于语句匹配到的行数**。比如 UPDATE 用相同值更新已有记录，MySQL 会跳过变更，ROW_COUNT() 就返回 0，哪怕 WHERE 条件匹配了 10 行。
常见误判场景：
- 执行
UPDATE t SET x=5 WHERE y=1，但所有匹配行的x已是5→ROW_COUNT()返回0 - 开启
sql_safe_updates=1且没带WHERE或主键条件 → 语句被拒绝，ROW_COUNT()仍为 -1（表示无影响），但你可能误以为执行成功了 - 触发器内部执行的 DML 不会影响外部
ROW_COUNT()，它只统计“最外层”语句
如何安全获取真正被修改的行数？
如果业务逻辑依赖“是否真有数据变化”，不能只信 ROW_COUNT()，得结合 FOUND_ROWS() 或显式检查。
推荐做法：
- 对
UPDATE，加WHERE ... AND col != new_value条件过滤掉无效更新（需注意 NULL 处理） - 用
SELECT ROW_COUNT()紧接在 DML 后立即执行，中间不能穿插任何其他语句（包括SELECT） - 在存储过程中，可配合
IF ROW_COUNT() > 0 THEN ... END IF做分支，但要确认该判断符合业务语义（比如“有变更” vs “有匹配”）
示例：
UPDATE users SET status = 'active' WHERE id = 123 AND status != 'active'; SELECT ROW_COUNT(); -- 这里才真正反映改了几行
客户端调用时容易忽略的连接隔离问题
每个 MySQL 连接维护独立的 ROW_COUNT() 状态，这意味着：
- PHP 的
mysqli中，必须用mysqli_affected_rows($conn)，而不是再发一次SELECT ROW_COUNT() - Python 的
pymysql或mysql-connector-python中，DML 执行后直接查cursor.rowcount，它底层就是ROW_COUNT() - 如果用了连接池（如 HikariCP），不同请求可能复用同一连接，
ROW_COUNT()可能被前一个请求残留 —— 必须在 DML 后立刻读取，不能延迟
替代方案：什么时候该放弃 ROW_COUNT()？
当需要精确知道“哪些行被改了”或“改前/改后值”，ROW_COUNT() 完全不够用。这时候得换思路：
- 用
SELECT ... FOR UPDATE先查再改，自己计数并记录 ID 列表 - 开启 binlog 并解析事件（适用于审计或同步场景，但开销大）
- 在应用层加版本号或时间戳字段，靠对比判断是否真变
尤其要注意：在批量 INSERT ... ON DUPLICATE KEY UPDATE 场景下，ROW_COUNT() 返回的是“插入 + 更新”的总和，无法拆分，这种模糊性常导致业务逻辑出错。
