由 dawei MySQL事务是保证数据一致性的核心机制，其ACID特性依赖于底层的锁与日志机制。理解事务隔离级别对性能影响至关重要：READ UNCOMMITTED极少使用；READ COMMITTED避免脏读但可能引发不可重复读；REPEATABLE READ（MySQL默认）通过MVCC解决大部分并发问题，却可能因间隙锁导致死锁；SERIALIZABLE则以全局串行化牺牲性能换取强一致性。
合理选择事务边界能显著提升吞吐量。避免将SELECT、日志记录等非关键操作包裹在长事务中；单次事务内应尽量只修改必要数据，并确保操作尽可能快完成。批量插入或更新建议分批次提交（如每1000条COMMIT一次），既减少锁持有时间，又防止undo log过度膨胀。
索引是事务性能的隐形支柱。无索引的WHERE条件会导致全表扫描并加行级锁升级为表级锁，极大增加冲突概率。尤其在UPDATE/DELETE语句中，务必确认执行计划使用了有效索引。•避免在事务中调用非确定性函数（如NOW()多次调用）、触发器或存储过程，以防隐式扩展事务范围。
InnoDB缓冲池（innodb_buffer_pool_size）应设为物理内存的50%–75%，过小导致频繁磁盘I/O，过大则挤压系统其他资源。监控Innodb_row_lock_waits和Innodb_row_lock_time_avg可快速识别锁争用瓶颈。对于高并发写场景，考虑拆分热点表、引入应用层排队或使用乐观锁替代悲观锁。
正确使用SAVEPOINT可实现细粒度错误恢复，避免整事务回滚开销；但嵌套过深会增加undo日志管理负担。同时禁用自动提交（SET autocommit=0）后，必须显式COMMIT或ROLLBACK，否则连接空闲事务将长期占用资源并阻塞 purge线程。
AI设计草图，仅供参考
每次SQL执行前，先用EXPLAIN分析执行计划；上线前在压测环境中模拟真实并发压力，观察事务等待时间与死锁频率。记住：没有银弹，最佳实践需结合业务读写比例、数据规模及一致性要求动态调整——性能优化的本质，是权衡的艺术。