互联网项目中mysql应该选什么事务隔离级别(原理剖析)

本文探讨了MySQL在互联网项目中为何通常选用读已提交(Read Commited)而非默认的可重复读(Repeatable Read)作为事务隔离级别。文章分析了MySQL选择可重复读作为默认隔离级别的历史原因,涉及主从复制和binlog格式。同时,对比了两种隔离级别在死锁、锁表和并发性上的差异,指出在RC级别下,虽然可能出现不可重复读,但在互联网项目中是可接受的,并推荐使用row格式的binlog以保证主从复制的一致性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

引言

开始我们的内容,相信大家一定遇到过下面的一个面试场景

面试官:“讲讲mysql有几个事务隔离级别?”  

你:“读未提交,读已提交,可重复读,串行化四个!默认是可重复读”

面试官:“为什么mysql选可重复读作为默认的隔离级别?”   

(你面露苦色,不知如何回答!)   

面试官:"你们项目中选了哪个隔离级别?为什么?"  

你:“当然是默认的可重复读,至于原因。。呃。。。”   

(然后你就可以回去等通知了!)

为了避免上述尴尬的场景,请继续往下阅读!   
Mysql默认的事务隔离级别是可重复读(Repeatable Read),那互联网项目中Mysql也是用默认隔离级别,不做修改么?
OK,不是的,我们在项目中一般用读已提交(Read Commited)这个隔离级别!
what!居然是读已提交,网上不是说这个隔离级别存在不可重复读幻读问题么?不用管么?好,带着我们的疑问开始本文!

 

正文

我们先来思考一个问题,在Oracle,SqlServer中都是选择读已提交(Read Commited)作为默认的隔离级别,为什么Mysql不选择读已提交(Read Commited)作为默认隔离级别,而选择可重复读(Repeatable Read)作为默认的隔离级别呢?

到底是为什么呢?

下面我们来细说原因:

这个是有历史原因的,当然要从我们的主从复制开始讲起了!
主从复制,

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值