ROW_COUNT()仅返回上一条DML语句影响的行数（正整数、0或-1），不提供被修改行的具体数据、主键或字段变更详情；因其仅为会话级状态值，无内容缓存，故无法直接查出“哪些行、如何变”。
ROW_COUNT() 只返回数字，不返回行详情 它不是 SELECT 语句，不能查出哪几行被改了、改前改后值是什么。想看“哪些行”，必须换思路：要么提前查，要么用 RETURNING（MySQL 不支持），要么加日志或触发器。
为什么 ROW_COUNT() 拿不到具体行数据
MySQL 的 ROW_COUNT() 是会话级状态函数，只保存上一条 DML（INSERT/UPDATE/DELETE）的变更计数，底层对应的是存储引擎层的「实际变更行数」。它不缓存行内容、不记录主键、不生成中间结果集——所以你调用它时，得到的永远是 0、1 或 127 这样的整数，没有字段、没有 ID、没有旧值新值。
常见误解包括：
- 以为
SELECT ROW_COUNT(), id, name FROM users WHERE ...能拼出结果（语法错误，ROW_COUNT()不能和表字段混在同一个 SELECT 里） - 执行完
UPDATE后隔了一条SELECT 1再查ROW_COUNT()（此时已被重置为-1或0） - 在存储过程中调用了多个 SQL，却忘了
ROW_COUNT()只反映最近那条
想看到“哪些行被影响”，得组合操作
真正可行的路径只有三条，选哪条取决于你的场景和权限：
- 先
SELECT id, name, age FROM users WHERE age 记下原始数据，再执行UPDATE users SET status = 'minor' WHERE age ，最后比对（适合小批量、可离线验证） - 用
UPDATE ... JOIN把原表和待更新集合显式关联，再套一层子查询包装成 SELECT（例如：SELECT u.id, u.name, u.age AS old_age, 18 AS new_age FROM users u JOIN (SELECT id FROM users WHERE age ） - 开启 MySQL general_log 或使用 performance_schema.events_statements_history_long 表抓取完整语句+时间戳，配合应用层打点定位（适合排查线上异常，但开销大）
PyMySQL / MySQL Connector 等驱动里的 rowcount 也是同样逻辑
比如 Python 中写：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
cursor.execute("UPDATE users SET score = score + 10 WHERE level = 'vip'")
print(cursor.rowcount) # 输出 3，仅此而已
这个 cursor.rowcount 底层就是调用 ROW_COUNT()，它不会自动帮你回查主键列表。如果你需要同时拿到 ID 列表，必须显式多走一步：
- 要么用
SELECT id FROM users WHERE level = 'vip'先查一遍（注意并发下可能有偏差） - 要么在 UPDATE 前加事务并锁行：
SELECT id FROM users WHERE level = 'vip' FOR UPDATE，再 UPDATE，确保一致性 - 要么改用带触发器的日志表，每次 UPDATE 触发 INSERT INTO update_log (table_name, pk_id, old_data, new_data) VALUES (...)
真正难的不是“怎么拿数字”，而是“怎么确认这数字对应哪几行”——MySQL 本身不提供原子级的“变更快照”，所有绕过方案都需权衡一致性、性能与侵入性。
