mysql默认事务隔离级别有哪些

这是一个陷阱，不要使用ReadUncommited。

MySQL四种隔离级别是什么？分别怎么实现的？

MySQL的四种隔离级别是：未提交读、提交读、可重复读和序列化。

读取未提交：可以读取未提交的数据。
这就像买火车票一样。
你刚刚查了一下，你没有买。
别人买了然后退款了。
查了一下，还是别人买的。
没有锁定或版本控制。

阅读提交：提交后才能阅读。
就像等待确认消息一样。
如果其他人购买了它，在您确认之前您将看不到它。
使用版本控制或日志来确保提交完成。

可重复读取：事务内的一致读取。
就像酒店的价目表，你看两遍，即使别人把房间卖了，加价了，它还是原价。
使用MVCC+间隙锁来防止数据插入。

序列化：执行完全锁定。
这就像排队等候，在你完成之前没有其他人可以进去。
使用两阶段锁定协议将其完全隔离。

自己掂量一下。

老男孩教育 | 面试被问烂的 MySQL 数据库服务隔离级别，建议收藏！

说实话，我在做的过程中弄清楚了如何理解MySQL事务隔离级别。
以RU（未提交读）为例。
这个东西基本上是金融体系中的禁区，但是在一些统计场景中还是可能会看到的。
我之前曾在一家电子商务公司做过项目。
临时需要快速向运营提供销售数据，因此数据库临时将隔离级别调整为RU。
结果呢？ 运营阿姨看着报表数据，喊着要每天重跑。
因为后台有促销活动没有提交，所以她直接读取了脏数据。
最后只能添加一个定时任务，晚上系统压力较低的时候再跑一次准确的数据。

有趣的是，RC（已提交读）是 MySQL 中的默认值。
就像是脂肪的妥协，既不太胖，也不太瘦。
我经常在我的服务器的慢查询日志中看到它，特别是当数据被大事务修改然后被小事务重复读取时。
例如，一位用户反映APP在刷新订单列表时卡住了。
后来经过排查，发现后端查询隔离级别设置为RC，每次查询都要检查数据版本。
将隔离级别调整为RR后，虽然并发确实下降了1 0%左右，但用户抱怨明显减少了。

说起RR（可重复读），我并没有亲自跑过InnoDB的具体场景，但是文档中提到的间隙锁听起来还是蛮有趣的。
去年，一位客户抱怨订单统计不准确。
经过查找，他发现有两笔交易同时检查一定范围的订单，一笔在锁定，另一笔在插入新订单，导致统计结果不稳定。
最后通过切换到RR级别并配合事务隔离，问题基本解决。
不过RR的锁开销确实不小。
我的一个朋友在双十一期间调整参数时，为了将事务隔离改为RR，CPU峰值飙升至9 0％以上，最终他不得不妥协回RC。

至于SR（Serialized），这个东西就像是数据库世界里的极端分子。
我在银行系统中见过一次。
他们在处理运行调节时必须使用 SR。
否则，当一个事务正在检查数据，而另一个事务插入具有相同ID的记录时，对账就会爆炸。
那段时间数据库QPS直接下降到正常值的1 /1 0，运维小哥每天都在监控面前抓狂。
但说实话，在这种极端场景下确实需要SR。
金融行业对数据一致性有着严格的要求。

在操作命令方面，我有一个习惯，每次接新项目时，我都会在开发环境中将隔离级别更改为RR，因为默认值虽然方便，但很容易出现问题。
我记得在一次测试上线之前，我大手一挥就把全局隔离级别改成了RU。
幸好DBA发现得早，不然就出大事了。
我也是用命令暂时关闭autocommit，比如更改数据前SET GLOBAL autocommit=0，更改数据后COMMIT。
这比显式声明事务更简单。

关键词分析、脏读给我印象最深的是一次深夜测试。
我正在RC层面检查数据，但是另一个事务疯狂删除了数据。
我看着屏幕上的数字跳动，当时我真的很困惑。
不可重复阅读更为常见。
例如，当用户修改订单详情时，两次看到的金额可能完全不同。
我很少遇到幻影看了一下，但理论上来说，查询条件确实有可能在一定范围内变化。

总结一下，RU适合临时统计，RC适合大部分场景，RR适合大部分业务，SR适合金融这种可怕的一致性要求。
但说实话，选择哪一个级别最终还是要看业务场景。
我有一个项目，最终选择了RC。
业务方觉得RR的锁开销太大。
他们宁愿数据偶尔波动也不愿牺牲系统性能。
数据一致性和并发性确实没有完美的答案。