由 dawei MySQL事务是保证数据一致性的核心机制，但不当使用会显著拖慢系统性能。理解事务隔离级别与锁行为是优化的前提。
默认的REPEATABLE READ隔离级别在高并发写入场景下易引发间隙锁（Gap Lock），导致不必要的锁等待。若业务允许读取已提交数据，可将隔离级别降为READ COMMITTED，减少锁范围，尤其适用于订单、日志等实时性要求高的场景。
长事务是性能杀手。事务开启后未及时提交或回滚，会持续持有锁并阻碍MVCC版本清理，加剧undo日志膨胀和主从延迟。应设置transaction_timeout（如30秒），并通过监控工具（如information_schema.INNODB_TRX）定期扫描运行超时的事务。
AI绘图结果，仅供参考
索引缺失会让UPDATE/DELETE语句升级为表级锁。务必确保WHERE条件字段有高效索引，避免全表扫描。执行前用EXPLAIN验证执行计划，拒绝无索引的行更新操作。
批量写入应合并为单条INSERT … VALUES(…),(…),(…)，而非循环逐条INSERT。同样，大批量更新建议分批次（每次1000行以内）+ COMMIT，既控制事务大小，又避免长锁与回滚段过大。
死锁无法完全避免，但可降低频率：保持固定顺序访问多张表；尽量缩短事务内SQL执行路径；应用层捕获Deadlock异常（Error 1213）后主动重试，而非抛错中断。
关闭autocommit后手动管理事务时，需严格配对BEGIN/START TRANSACTION与COMMIT/ROLLBACK。遗漏ROLLBACK会导致连接隐式持锁，最终耗尽连接池资源。建议使用try-finally或框架事务管理器强制保障。
监控不可少：关注Innodb_row_lock_waits、Innodb_deadlocks及Slow_queries，结合pt-query-digest分析慢事务。生产环境禁用SET GLOBAL tx_isolation，所有变更通过会话级设置并留痕。
最小化事务粒度比“加索引”更关键——只包裹真正需要原子性的逻辑。例如用户积分变更可拆为“扣减”和“记录”两个独立事务，配合最终一致性补偿，大幅提升吞吐。