开启innodb_rollback_on_timeout=on后，锁超时触发error 1205时innodb会回滚整个事务而非仅最后一条语句，但应用必须捕获错误并实现幂等重试，且该参数为只读，云数据库需通过参数组修改并重启生效。
锁超时后整个事务回滚，应用必须自己重试
开启 innodb_rollback_on_timeout = ON 后，一旦触发 ERROR 1205 (HY000): Lock wait timeout exceeded，InnoDB 会中止并回滚整个事务——不是只回滚最后一条语句。这看似更“安全”，但代价是：应用层必须捕获该错误，并主动重试整个业务逻辑。
- Spring 的
@Transactional(timeout=...)对锁等待超时无效，它只控制事务开始后的执行时间，不干预底层行锁等待；真正起作用的是innodb_lock_wait_timeout - 若应用没做重试封装（比如没用
@Retryable或手动 try-catch + 重放），直接向上抛错，会导致业务中断、前端报 500、下游调用失败 - 重试逻辑本身要幂等：插入不能重复、状态变更不能叠加、补偿动作需可重复执行
云数据库上无法动态修改，改错配置可能引发服务中断
innodb_rollback_on_timeout 是只读全局变量，SET GLOBAL 在绝大多数生产环境（阿里云 RDS、腾讯云 CDB、AWS RDS、MySQL 8.0+）会直接报错：ERROR 1238 (HY000): Variable 'innodb_rollback_on_timeout' is a read only variable。
- 本地 MySQL 允许修改配置文件后重启生效，但线上云实例必须走「参数组」流程：新建/编辑参数组 → 设为
ON→ 绑定到实例 → 触发重启（部分厂商支持平滑重启，但仍有短暂不可用窗口） - 误操作（如参数组未保存、绑定未生效、重启失败）会导致配置未落地，而你以为已开启，实际仍是默认
OFF，隐患仍在 - RDS 控制台里某些旧版参数组不显示该选项，需先升级参数模板版本才能看到
与 innodb_deadlock_detect 和 innodb_lock_wait_timeout 耦合紧密
单独开 ON 不解决问题，它必须和另外两个参数协同调整才有意义：
- 若
innodb_deadlock_detect = ON（默认），高并发下死锁检测开销大；此时建议关掉它，靠innodb_lock_wait_timeout主动超时释放锁——但这就更依赖innodb_rollback_on_timeout = ON来保证事务原子性 -
innodb_lock_wait_timeout值设太小（如 1 秒），在复杂事务或慢查询场景下容易误触发超时；设太大（如 50 秒默认值），又会让锁堆积更久，拖垮整体吞吐 - 三者组合典型配置：
innodb_deadlock_detect = OFF+innodb_lock_wait_timeout = 3+innodb_rollback_on_timeout = ON，但必须压测验证是否匹配你的业务节奏
事务日志和 Binlog 记录行为会变化
MySQL 9.6.0 起，外键与级联操作上移至 SQL 层，所有变更完整写入 Binlog。但在此之前版本（包括主流的 5.7/8.0），innodb_rollback_on_timeout = ON 导致整个事务回滚时，Binlog 中不会记录任何内容——因为事务没提交，也就没生成事件。
- 对 CDC（Debezium/Flink CDC）、主从复制、审计溯源无影响，这是正确行为
- 但如果你依赖 Binlog 解析做“事务重放”或“变更补偿”，要注意：超时回滚的事务在 Binlog 里完全不可见，不能靠它重建状态
- 应用层补偿逻辑必须基于业务表状态判断，而非 Binlog 流式消费
commit 仍能成功执行，而你之前那条 UPDATE 已静默回滚——表里数据看起来“半途而废”，却没有任何异常提示。
