mysql事务是并发执行还是同步执行

mysql事务是并发执行还是同步执行，核心结论先给你：数据库层面的事务是「并发执行」的，但通过事务的隔离机制，会让事务之间看起来「好像是有序执行」（同步感），以此避免并发带来的数据混乱问题。

简单说：「底层是并发，上层靠隔离做“同步效果”」，这是数据库为了兼顾「性能」和「数据一致性」的设计。

在讨论这个问题前，先明确两个容易搞混的术语，避免理解偏差：

并发执行：多个事务在同一时间段内同时推进（比如事务A执行查询、事务B同时执行更新），数据库会通过CPU调度、IO多路复用等机制同时处理多个事务请求，这是数据库提升吞吐量的核心（如果所有事务都同步排队，高并发场景下数据库会直接瘫痪）。
同步执行（串行执行）：多个事务按先后顺序执行，只有前一个事务完全提交/回滚，后一个事务才能开始执行，这种方式数据最安全，但性能极差，几乎只在极端严格的场景下使用。

核心原因是提升性能和资源利用率。
想象一下，电商平台的秒杀场景，同一时间有上万个用户下单（对应上万个事务），如果事务是同步串行执行，第一个用户的事务执行完（查询库存→扣减库存→生成订单），第二个用户才能开始，那后续用户可能要等几个小时才能完成下单，这显然是不可接受的。

而并发执行可以让多个事务同时占用数据库资源（CPU、内存、IO），比如事务A在等待磁盘IO读取数据时，数据库可以调度CPU去处理事务B的逻辑，大幅提升单位时间内的事务处理量（吞吐量）。

事务并发执行虽然高效，但如果不加控制，会出现脏读、不可重复读、幻读等问题（比如你之前问的“查询-更新”超卖问题，本质就是并发事务未隔离导致的）。

数据库的事务隔离级别（由SQL标准定义，不同数据库有实现差异）就是用来解决这个问题的，它相当于在“并发执行”的底层上，加了一层“规则”，让事务之间互不干扰，呈现出“有序执行”的效果。具体隔离级别对应解决的问题如下：

隔离级别	能否脏读	能否不可重复读	能否幻读	并发性能
读未提交（Read Uncommitted）	能	能	能	最高
读已提交（Read Committed）	不能	能	能	较高（MySQL/PostgreSQL默认）
可重复读（Repeatable Read）	不能	不能	不能（MySQL优化后）	中等（InnoDB默认）
串行化（Serializable）	不能	不能	不能	最低（同步串行执行）

前三个隔离级别（读未提交、读已提交、可重复读），底层依然是事务并发执行，数据库通过「锁机制」（行锁、表锁）和「MVCC（多版本并发控制）」来实现隔离，既保证并发性能，又避免数据混乱。
只有最高级别「串行化」，才是真正的同步串行执行——数据库会对事务涉及的表/行加排他锁，一个事务执行期间，其他事务只能排队等待，直到当前事务结束，这种方式完全没有并发性能可言，仅适用于数据一致性要求极高、并发量极低的场景（比如财务对账的核心数据修改）。

假设现在有两个事务，同时操作同一个商品的库存（初始库存=1）：

无隔离的并发执行：事务A和B同时查询到库存=1，然后都执行扣减，最终库存=-1（超卖，数据混乱）。
开启可重复读隔离级别的并发执行：数据库通过MVCC和行锁，让事务A先锁定该商品的库存行，事务B的查询和更新会被阻塞（等待事务A释放锁），直到事务A提交（库存变为0），事务B才能查询到库存=0，进而无法执行扣减。
- 从底层看：事务A和B是并发提交的请求，数据库在处理时存在“并行调度”。
- 从业务效果看：事务A先执行完成，事务B后执行，看起来和“同步串行”一样，且避免了超卖，同时兼顾了性能（其他不操作该商品的事务依然可以正常并发执行）。

你可能还会遇到应用层的事务调用（比如Java中多线程调用带@Transactional的方法），这里要注意区分：

数据库层面：事务本身是并发执行的（除非串行化隔离级别）。
应用层：如果是多线程同时发起事务请求，这些请求会被数据库并发处理；如果是单线程按顺序发起事务请求，那事务会被数据库按顺序处理（但这是应用层的同步，不是数据库事务的同步）。

版权属于：Joyber
本文链接：https://blog.qqvbc.com/default/1421.html
转载时须注明出处及本声明