由 dawei MySQL事务是保证数据一致性与完整性的核心机制，其ACID特性（原子性、一致性、隔离性、持久性）在电商场景中尤为关键。下单、扣库存、更新账户余额等操作必须全部成功或全部回滚，任何中间状态泄露都可能导致超卖或资金异常。
隔离级别直接决定并发行为。读未提交易引发脏读；读已提交避免脏读但可能不可重复读；可重复读（MySQL默认）通过MVCC实现快照读，解决幻读问题；串行化则以性能为代价彻底消除并发冲突。电商系统通常选用可重复读，兼顾正确性与吞吐量。
高并发下事务冲突常表现为锁等待甚至死锁。InnoDB的行级锁并非万能：全表扫描会升级为表锁；非唯一索引更新可能锁定间隙（Next-Key Lock），阻塞范围插入；长事务会持有锁过久，拖慢整体响应。监控`innodb_trx`和`information_schema.INNODB_LOCK_WAITS`可定位瓶颈。
建议图AI生成，仅供参考
实战中需主动规避风险。订单创建时采用“先扣库存再生成订单”而非“先生成再扣”，减少事务持锁时间；库存表按商品ID分片或使用乐观锁（版本号/时间戳+重试），避免热点行争用；对非核心业务如日志写入，剥离至异步队列，缩短主事务链路。
事务边界设计影响显著。Spring中`@Transactional`若误用在service层过粗粒度方法上，会导致锁持有时间远超必要；而DAO层细粒度控制又增加协调复杂度。建议以单一业务实体变更（如一次订单+库存联合变更）为最小事务单元，并配以幂等性设计应对网络重试。
持久性依赖redo log刷新策略。`innodb_flush_log_at_trx_commit=1`确保每次提交落盘，但影响性能；电商系统可在部分非核心场景设为2（每秒刷盘），辅以主从强同步保障数据安全。最终平衡点在于SLA要求：支付类操作必须严格ACID，营销活动类可适度降级。