mysql存储过程无内置重试机制，必须用repeat/while循环+start transaction/rollback显式控制；exit handler会退出块无法重试，continue handler不解决事务异常状态，仅能配合失败标志实现安全重试。
不能直接重试——MySQL存储过程没有内置重试机制，必须手动写循环+条件判断，且重试前要确认错误是否可重试（比如23000可以，45000或22012通常不行）。
为什么不能用EXIT HANDLER做重试？
EXIT HANDLER触发后会立刻退出当前BEGIN...END块，无法回到出错语句前继续执行。CONTINUE HANDLER虽然不退出，但事务状态已标记为异常，后续DML仍可能被回滚或报错，强行续跑风险极高。
-
DECLARE EXIT HANDLER FOR SQLSTATE '23000'→ 进入handler后BEGIN...END就结束了，没机会再执行INSERT -
DECLARE CONTINUE HANDLER FOR SQLSTATE '23000'→ handler执行完继续往下走，但此时事务已处于“异常中”状态，下一条INSERT大概率失败或被隐式回滚 - 真正能控制流程的只有显式
START TRANSACTION+ROLLBACK+REPEAT/WHILE循环
怎么安全地实现“捕获23000并重试”？
核心思路：把单次DML封装进循环，每次失败都ROLLBACK，清空错误标志，再试一次。关键不是靠HANDLER“捕获后重试”，而是靠循环+CONTINUE HANDLER仅作“标记失败”。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 先用
DECLARE CONTINUE HANDLER FOR SQLSTATE '23000'设一个失败标志（如SET @failed = 1），不ROLLBACK——因为事务还在运行中 - 用
REPEAT ... UNTIL @failed = 0 OR @retry_count > 3包裹整个事务逻辑 - 每次循环开头
START TRANSACTION，结尾COMMIT；失败时ROLLBACK，然后ITERATE重来 - 必须在循环内
SET @failed = 0初始化，否则第二次循环直接跳过
REPEAT
SET @failed = 0;
START TRANSACTION;
INSERT INTO users(name, email) VALUES (@name, @email);
IF @failed = 0 THEN
COMMIT;
ELSE
ROLLBACK;
END IF;
UNTIL @failed = 0 OR @retry_count > 3
END REPEAT;
哪些SQLSTATE适合重试？哪些绝对不能？
重试只对**瞬态冲突类错误**有意义，对语法、约束、权限类错误重试只是浪费资源甚至放大问题。
- ✅ 可考虑重试：
'23000'（主键/唯一键冲突）、'40001'（死锁），前提是业务逻辑允许覆盖或改写（比如生成新UUID再插） - ❌ 禁止重试：
'22003'（数值越界）、'22012'（除零）、'42S02'（表不存在）、'45000'（自定义业务错误）——这些是硬性错误，重试100次结果一样 - ⚠️ 注意：
'HY000'太宽泛，匹配到23000也匹配到1213（死锁），但两者重试策略不同，应避免用它做条件
最容易被忽略的并发与事务陷阱
重试逻辑本身会放大并发问题：两次重试可能同时查到同一空位，又同时插入，导致第二次仍23000。这不是HANDLER写得不对，而是架构层面没解决。
- MyISAM表不支持事务，
ROLLBACK无效，重试毫无意义——必须用InnoDB - DDL语句（如
CREATE TEMPORARY TABLE）会隐式提交，导致前面的INSERT无法回滚，重试时事务边界已乱 - 如果重试逻辑里包含
SELECT ... FOR UPDATE，要注意锁等待超时（innodb_lock_wait_timeout），否则卡住连接 - 应用层调用该存储过程时，也要配合设置连接超时和重试次数，避免数据库端重试了3次，客户端又重试3次，变成9次无谓请求
