mysql中row_count()返回0的最常见原因是where条件未匹配到任何行，语句执行成功但无实际影响，需用select复现条件验证、注意大小写、null判断、空格、事务提交状态、触发器干扰及类型隐式转换等问题。
WHERE条件没匹配到任何行
这是最常见也最容易被忽略的原因：语句执行成功，但ROW_COUNT()返回0。MySQL不报错，只默默跳过。
- 先用
SELECT * FROM table_name WHERE ...复现你的WHERE条件，确认能查出至少一行 - 注意大小写——PostgreSQL和启用了
lower_case_table_names=0的MySQL区分列名大小写 - 别直接写
WHERE status = NULL，正确写法是status IS NULL - 字符串字段可能带不可见空格，试试
WHERE TRIM(status) = 'active'或LENGTH(status)验证
事务没提交，或者根本没开启自动提交
UPDATE只是改了当前事务快照里的数据，其他会话看不到，连接断开就丢。
- 查当前状态：
SELECT @@autocommit;（MySQL）、SHOW TRANSACTION ISOLATION LEVEL;（PostgreSQL） - 如果
@@autocommit = 0，每次UPDATE后必须显式COMMIT，否则只在本连接可见 - ORM里不是
.save()或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对重复值更新不记日志也不改数据，而类型不匹配时可能静默截断、转默认值甚至全表扫描漏匹配。
- 执行UPDATE前先
SELECT col FROM table WHERE pk = x，确认原值真不一样 - 对
VARCHAR字段用数字比较（如WHERE code = 123），MySQL会逐行转类型，慢还容易漏——改用WHERE code = '123' -
ENUM字段赋非法字符串，可能变成空串或默认值，表面看不出异常 - 数值字段超范围（如
TINYINT赋300），MySQL会转成127或-128，不是报错而是静默修正
真正麻烦的从来不是语法错，而是那些不报错、不阻塞、ROW_COUNT()还显示“成功”的静默干扰——尤其是触发器和事务隔离的组合，查起来要一层层剥开看。
