UPDATE影响行数为0不报错是正常行为，背后对应两种业务状态：一是WHERE未匹配到任何行（Rows matched: 0），二是匹配到但新旧值相同导致InnoDB跳过写入（Changed: 0）；需通过SELECT验证WHERE、比对新旧值、检查事务状态及程序rowcount读取逻辑逐层排查。
UPDATE影响行数为0不报错，是正常行为，但背后可能对应两种完全不同的业务状态：要么数据根本没找到，要么找到了但值没变。不能只看“没报错”就认为逻辑走通了。
WHERE条件是否真能匹配到行
这是最常见原因。UPDATE执行成功，但Rows matched: 0，意味着WHERE一个都没捞出来。
- 直接把WHERE部分拎出来跑
SELECT，比如UPDATE users SET status = 'active' WHERE id = ?，先查SELECT * FROM users WHERE id = 123 - 注意字符串字段的隐式截断或空格问题：
SELECT HEX(name), LENGTH(name) FROM users WHERE id = 123 - 数字字段传了非法字符串，如
WHERE user_id = 'abc100'会被转成0，若表中无user_id = 0，就彻底失联 - 大小写敏感排序规则下比较失败，例如
status字段用的是utf8mb4_0900_as_cs，WHERE status = 'shipped'不会匹配'Shipped'
新值是否与原值完全一致
即使WHERE命中了N行，也可能因值未变导致Changed: 0——InnoDB会跳过物理写入，ROW_COUNT()返回0。
-
NULL比较必须用IS NULL，= NULL永远为FALSE，容易写出无效条件 -
CHAR字段末尾空格在比较时可能被忽略（PAD SPACE属性影响），但存储时已填充 - 时间戳精度不一致：应用层只设到秒级，数据库存的是微秒级，肉眼相同，实际不同
- 触发器（
BEFORE UPDATE）可能把NEW.status又设回OLD.status，最终白忙一场 - 稳妥做法是显式排除不变场景：
UPDATE users SET status = 'done' WHERE id = 123 AND (status != 'done' OR status IS NULL)
事务未提交或autocommit关闭
UPDATE语句执行了，但其他连接查不到，甚至本连接再查也看不到更新后的值，大概率是事务卡住了。
- MySQL查
SELECT @@autocommit，返回0说明需手动COMMIT；再查SELECT @@in_transaction确认当前是否在事务中 - PostgreSQL运行
SHOW TRANSACTION ISOLATION LEVEL，并检查pg_stat_activity里是否有idle in transaction - ORM如SQLAlchemy必须调
session.commit()，session.flush()只同步SQL，不落库 - Go/Python/Java等语言驱动默认
autocommit=False很常见，别依赖默认值，初始化连接时显式设置 - 协程环境（如gevent + Django）可能因连接复用导致事务状态交叉污染，换
syncworker可快速验证
程序里没检查rowcount就认定更新成功
很多代码只判断err == nil，却忽略RowsAffected()或cursor.rowcount，导致幂等更新、状态流转类逻辑静默失败。
- Go用
result.RowsAffected()，注意参数顺序错位会导致WHERE条件值被当SET值用（如uid = '2025-01-01'） - Python PyMySQL/psycopg2用
cursor.rowcount，但若autocommit=False且未提交，旧版本可能返回-1 - Java JDBC必须用
PreparedStatement.executeUpdate()，它返回int；execute()不保证有意义 - MyBatis默认返回的是“匹配行数”，不是“受影响行数”，
update()返回1不代表数据真变了
真正麻烦的不是“找不到行”或“值没变”，而是这两者混在一起，再加上框架封装、事务隔离、驱动差异，让0这个数字承载了太多歧义。每次看到0 rows affected，都得像拆炸弹一样逐层排除：先SELECT验证WHERE，再比对新旧值，再查事务状态，最后盯住程序里的rowcount读取逻辑——少一步，就可能漏掉关键线索。
