MySQL里执行UPDATE后，ROW_COUNT()返回0，这事看着简单，但踩坑的人真不少。语句执行成功，没报错，但数据就是没变——排查起来往往比语法错误更磨人。最常见的原因其实就几个方向，下面一个一个拆开说。
WHERE条件没匹配到任何行
这是最容易被忽略的：UPDATE跑完了，ROW_COUNT()显示0，MySQL不报错，也不提醒你，就这么默默跳过。问题出在哪儿？
- 先拿
SELECT * FROM table_name WHERE ...把WHERE条件原样跑一遍，确认能查出至少一行数据。这一步看似多余，但能筛掉八成问题。 - 注意大小写。PostgreSQL和MySQL（
lower_case_table_names=0模式下）对列名大小写敏感，字符串比较也一样。如果条件写的是status = 'Active'，但实际存的是'active'，那就匹配不上。 - 别直接写
WHERE status = NULL。NULL不能用等号判断，正确写法是status IS NULL。这个坑太经典了，但每次都能抓到人。 - 字符串字段里可能藏着不可见空格。试试
WHERE TRIM(status) = 'active'，或者用LENGTH(status)看看实际长度，经常能发现多出来的空格或换行符。
事务没提交，或者根本没开启自动提交
UPDATE只是改了当前事务快照里的数据，其他会话看不到，连接一断开就全丢了。这个场景在ORM框架和命令行测试里特别常见。
- 查当前状态：MySQL用
SELECT @@autocommit;，PostgreSQL用SHOW TRANSACTION ISOLATION LEVEL;。如果@@autocommit = 0，每次UPDATE后必须显式COMMIT，否则只在本连接可见。 - ORM里不是调了
.sa ve()或session.execute(update)就完事了，还得显式调用session.commit()或transaction.commit()。不少新手在代码里改了数据，但没提交事务，查半天以为是数据库的问题。 - 命令行测试时，别被GUI工具“自动刷新”的假象蒙蔽。最好新开一个终端，用
SELECT亲自验证，这样才能确认数据是否真的持久化了。
触发器在背后悄悄改值
AFTER UPDATE触发器可能把刚写进去的值又覆盖掉，ROW_COUNT()显示1，但你查不到新值——因为触发器里又把值改回去了。这种情况排查起来最隐蔽。
- 查触发器：
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table' AND EVENT_MANIPULATION = 'UPDATE';。重点关注EVENT_TIMING是BEFORE还是AFTER，再看触发器体里有没有形如NEW.status := 'pending'之类的赋值。 - 注意
NEW.status = 'active'是判断，NEW.status := 'active'才是赋值——少个冒号，结果天差地别。 - BEFORE触发器里如果写了
SET NEW.amount = OLD.amount这种“拦截式赋值”，你update了但数据原样回滚，等于白忙一场。
值本身没变，或者类型隐式转换失效
MySQL对重复值更新不记日志也不改数据，所以如果新值和旧值一样，ROW_COUNT()返回0是正常的。另外，类型不匹配时可能静默截断、转默认值，甚至全表扫描漏匹配。
- 执行UPDATE前先
SELECT col FROM table WHERE pk = x，确认原值和新值确实不一样。有时候你以为改了，其实没变。 - 对VARCHAR字段用数字比较（比如
WHERE code = 123），MySQL会逐行做类型转换，不仅慢，还容易漏匹配——改成WHERE code = '123'就对了。 - ENUM字段赋非法字符串，可能变成空串或默认值，表面看不出异常，但数据就是没按预期走。
- 数值字段超范围（比如TINYINT赋300），MySQL会转成127或-128，不是报错而是静默修正。如果没意识到，查半天都找不到原因。
真正麻烦的从来不是语法错误，而是那些不报错、不阻塞、ROW_COUNT()还显示“成功”的静默干扰——尤其是触发器和事务隔离组合在一起的时候，查起来得一层层剥开看。下次遇到类似问题，不妨按这个顺序排查，大概率能省下不少时间。
