MySQL事务如何控制锁持有时间并可靠回滚

🔒 长事务为何放大故障

事务提供原子性和隔离能力，但数据库必须在事务结束前维持其一致性视图。写事务可能持有行锁直到提交或回滚；长时间未结束的读事务在某些隔离级别和实现下，也会妨碍旧版本清理。结果可能表现为锁等待上升、undo历史增长、存储空间压力、复制追赶变慢或连接池被占满。先确认事务持续时间及其实际资源影响，不要只根据“事务打开很久”推断一定有锁。

为关键事务记录开始时间、连接标识、调用来源、最后活动时间、涉及 SQL 和结束结果。将数据库事务时长与应用请求时间对齐，判断时间花在执行、锁等待，还是应用在事务打开时执行远程调用、序列化、等待队列或读取大量结果。检查锁等待链中的持有者和等待者；若阻塞来自一个远程服务超时期间未提交的事务，单纯优化索引无法解决根因。

📦 划定最小正确事务边界

在事务开始前完成不依赖数据库状态的输入校验、文件准备及外部服务查询。事务内只包含维护一致性所必需的读取与写入，并尽快提交。对同一组共享记录采用稳定的访问顺序，可减少相反顺序加锁引起的死锁。若业务操作必须跨越数据库与外部系统，数据库事务不能原子地覆盖 HTTP 请求、消息发布或对象存储写入；可考虑先记录待处理状态，再由可重试流程推进，并定义补偿或对账办法。

批量导入、清理和状态迁移可切为有界批次，以控制锁、日志和回滚量；但每批提交会改变部分成功语义。设计时应有可重复定位的游标或键范围、明确的续跑条件和幂等处理，避免失败后重复计数或漏行。批次大小不应凭空固定，应在代表性数据量和并发下观察事务时长与锁等待。

↩️ 错误、超时与重试

死锁与锁等待超时是并发事务可能遇到的正常失败类型，应用需要清楚知道当前数据库事务是否已被回滚、是否仍需显式结束，以及连接是否可继续复用。实现时按驱动和数据库行为验证具体错误路径。ROLLBACK撤销当前数据库事务中尚未提交的更改，却无法撤销已发送的邮件、HTTP 调用或独立提交的消息。客户端请求超时也不必然意味着服务器侧查询或事务已终止；盲目重试可能让原事务与新请求并存。

🧪 并发验证与验收

1. 设计两个事务竞争同一行、相反顺序访问两行、以及事务执行中外部依赖变慢的场景，记录预期结果和错误类型。
2. 验证死锁或超时发生后，应用关闭或归还连接前已完成必要回滚，不继续提交部分业务步骤。
3. 确认重试边界、幂等键及外部副作用去重机制，并验证有限重试耗尽后返回明确结果。
4. 比较发布前后事务时长分布、锁等待时长、死锁率、活动事务数、undo压力、复制延迟和重试率。

✅ 以一致性和时延一起验收

验收不应以“测试没有报错”结束。应确认竞争请求完成后数据约束成立、失败操作没有留下半成品、回滚后后续请求仍可使用连接，且高分位事务时长和等待有所改善。还需检查缩短事务是否引入了新的中间状态，并确保消费者或补偿流程知道如何处理。可靠事务设计既缩小锁窗口，也让失败后的状态可判定、可重试、可对账。