MySQL UPDATE 没生效但没报错
常见于
AUTOCOMMIT=1未开启、语句被静默忽略，或 WHERE 条件不匹配却误以为“失败”。先确认是否真没更新： 执行
SELECT ROW_COUNT()—— 返回
0表示没匹配到行，不是错误，是正常行为 检查 WHERE 中的字段类型：比如用字符串比较数字主键（
WHERE id = '1'对
INT字段会隐式转换，但若字段有索引且值超范围可能跳过） 确认表引擎：MyISAM 不支持事务，
UPDATE成功即写入；InnoDB 下若在事务中且未
COMMIT，其他会话查不到结果 注意触发器（
BEFORE UPDATE）里主动
SET NEW.col = OLD.col或
RETURN类逻辑（MySQL 8.0+ 支持），可能导致更新被拦截
事务中 UPDATE 报错后数据没回滚
根本原因是事务未正确管理 —— MySQL 默认不自动回滚异常，需显式控制。典型场景：
存储过程中未声明DECLARE EXIT HANDLER FOR SQLEXCEPTION，导致出错后继续执行后续语句，最后
COMMIT把部分成功操作提交了 应用层（如 Python/Java）捕获异常但忘了调用
connection.rollback()，连接复用时下次
COMMIT会把之前未提交的变更一起刷出去
START TRANSACTION后执行了 DDL（如
ALTER TABLE），MySQL 会自动提交当前事务，后续语句不在原事务内
DELIMITER $$
CREATE PROCEDURE safe_update()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
RESIGNAL; -- 重新抛出原错误
END;
START TRANSACTION;
UPDATE users SET status = 'active' WHERE id = 999999; -- 假设不存在
UPDATE orders SET paid = 1 WHERE user_id = 999999;
COMMIT;
END$$
DELIMITER ;唯一键冲突导致 UPDATE 失败但没提示具体字段
当
UPDATE触发
Duplicate entry错误（错误号
1062），MySQL 默认只说“重复键”，不指明是哪个唯一索引或哪列。排查要点： 用
SHOW CREATE TABLE tbl_name查所有
UNIQUE KEY和
PRIMARY KEY，重点关注组合唯一索引（如
UNIQUE KEY (a,b)） 检查
UPDATE语句是否修改了唯一索引覆盖的字段，例如：
UPDATE t SET b = 10 WHERE a = 5可能和另一行
(a=5, b=10)冲突 用
INSERT ... ON DUPLICATE KEY UPDATE替代纯
UPDATE可绕过冲突，但需确保业务逻辑允许“插入即更新” 错误信息里带的值（如
Duplicate entry 'xxx' for key 'uk_email'）中的
'xxx'是实际冲突的索引值，可反查对应行
长时间运行的 UPDATE 被 kill 或超时中断
这类“失败”往往卡在锁等待或执行超时，现象是客户端断开、日志出现
Killed或
Lock wait timeout exceeded（错误号
1205）： 查锁状态：
SELECT * FROM performance_schema.data_locks（MySQL 8.0+）或
SHOW ENGINE INNODB STATUS\G中的
TRANSACTIONS部分 避免长事务：UPDATE 前先
SELECT ... FOR UPDATE显式加锁虽可控，但若事务太久，会阻塞其他操作；更稳妥的是用
WHERE尽量缩小扫描范围 + 确保相关字段有索引 调整超时参数：临时加大
innodb_lock_wait_timeout（单位秒），但治标不治本；生产环境建议保持默认（50 秒），靠应用层重试 + 降级逻辑处理 注意 autocommit=0 下，一个未提交的 UPDATE 会一直持有锁，直到
COMMIT或
ROLLBACK—— 忘记这步是线上锁表的高频原因
事务异常真正难处理的，从来不是语法或配置，而是“以为自己 rollback 了”——比如在 try/catch 里只 log 了错误，没调
rollback()；或者存储过程 handler 里写了
ROLLBACK却漏了
RESIGNAL，上层应用误判为成功。
