update没报错但数据没变，大概率是where条件未匹配到任何行；应立即查row_count()、用select验证where、再执行show warnings。
UPDATE 没报错但数据没变，大概率是 WHERE 条件根本没匹配上任何行，而不是 SQL 写错了。 MySQL 对语法合法、逻辑无冲突的 UPDATE 一律返回 “Query OK, X rows affected”，哪怕 X 是 0。这时候你得立刻查 ROW_COUNT()，而不是看有没有错误提示。
WHERE 条件写对了但没命中：先用 SELECT 验证再执行
很多问题不是 SQL 本身有误，而是条件在当前数据里根本不存在。比如 WHERE user_id = 99999，但表里最大 id 只到 12345；或者 WHERE email = 'admin@gmil.com'（拼错 gmail）；又或者字段是 CHAR(20) 类型，存了 'alice '（带尾部空格），而你查的是 'alice'。
- 执行 UPDATE 前，把 WHERE 部分原样复制出来跑一遍
SELECT *，确认能查出至少一行 - 对字符串字段，加
LENGTH()或HEX()看有没有不可见字符：SELECT email, LENGTH(email), HEX(email) FROM users WHERE id = 123 - 区分大小写的排序规则（如
utf8mb4_0900_as_cs或_bin）下，'Admin'≠'admin'，别靠肉眼判断
隐式类型转换让 WHERE 失效：数字字段传字符串很危险
MySQL 在比较时会自动做类型转换，但转换规则不总符合直觉。比如 id 是 INT，你写 WHERE id = '123abc'，MySQL 会转成 WHERE id = 123；但若写 WHERE id = 'abc123'，就会变成 WHERE id = 0 —— 这时候除非真有一行 id = 0，否则就是 0 行影响。
- 对主键或数字索引字段，WHERE 中统一用数字字面量，避免引号包裹
- ENUM 字段慎用数字值比较：
status ENUM('pending','active')，WHERE status = 2会转成'active'，但若字段其实是VARCHAR就完全不等价 - 开启严格模式后，部分隐式转换会触发
Warning，记得执行完立刻跑SHOW WARNINGS
UPDATE 值和原值一样：MySQL 真的不会更新
如果新值和当前值完全一致（包括空格、大小写、NULL 性），InnoDB 会跳过实际写入，ROW_COUNT() 返回 0，且不报错。这不是 bug，是优化行为。
- 例如：
UPDATE users SET name = 'Alice' WHERE id = 123，而该行name已经是'Alice' - 用
SELECT先查原值，再比对；或改用带校验的写法：UPDATE users SET name = 'Alice' WHERE id = 123 AND name != 'Alice' - 注意 NULL 比较必须用
IS NULL或IS NOT NULL，= NULL永远为 false
最常被忽略的一点：你以为在改数据，其实只是在改一个“看起来一样”的副本——可能是事务未提交、字符集隐式截断、或是触发器悄悄把 NEW.col 设回了 OLD.col。每次看到 0 rows affected，先停手，查 ROW_COUNT()，再查 SELECT，最后看 SHOW WARNINGS。三步缺一不可。
