最易懂的数据库事务的四种隔离级别知识

那天，我在一家咖啡馆，看到我旁边的那个人在电脑屏幕上挠头。
原来是他在处理订单时写的代码有问题。
同一张订单，前一刻显示有足够的​​库存，后一刻就显示缺货。
这让我想起了数据库隔离级别。
这就像生活中的一段插曲，其中隐藏着一个大真相。

例如，在您的银行系统中，您想查看您的卡上的余额为 3 0,000。
这时系统出现bug，额外扣除了1 000日元。
突然间，您有更多的钱可以寄给您的朋友。
如果隔离级别较低，则传输过程中原始数据可见，传输会失败。
如果更高，当您检查余额时，您会发现它又回到原来的 2 9 ,000，并且您必须重新输入。
就像去菜市场买菜一样。
你刚刚称了西红柿的重量，但当你的老板突然改变秤时，你发现它们比预期轻了 0.5 公斤。

MySQL默认的REPEATABLE-READ是最常见的，但它有一个小缺陷。
例如，如果您查询同一订单两次，第一次看到有 5 0 件商品，第二次突然显示 4 0 件商品。
这是一本很棒的读物。
这让我想起了我在网上购物时遇到的一件事。
我刚把商品加入购物车的时候价格还是1 9 9 ，但是下单的时候突然变成了2 09 最后客服给我退了差价，但是当时我真的很迷茫。

一些公司使用READ COMMITTED来避免麻烦。
你可能会遇到“工资突然增加”之类的错误，但至少你不会看到像“脏读”中那样有人取消订阅后被清除的库存数据。
我记得有一次检查过同事的系统日志。
他注意到一笔交易的金额是负数。
然后我发现又一个未提交的事务被误读了。
这是一个经典的脏读。

等等，还有一件事。
金融系统中的隔离级别与 SERIALIZABLE 一样严格。
这和在超市排队结账是一样的。
虽然慢，但是即使喝了酱油也不会发现醋没了。
当我在银行实习时，我记得故意在我们的测试用例中添加并发场景。
结果，串行处理导致系统长时间挂起。
一位顾客正在柜台前等候。
最后，经理有些担心地挠着头。

我突然想到分布式数据库有一些比传统隔离级别更灵活的新技巧，比如使用乐观锁来解决幻读。
不过话虽如此，在处理高并发场景时，使用 REPEATABLE-READ 还是 READ COMMITTED 取决于业务。
这取决于场景。
与水管维修类似，必须完全拆除并重新安装（SERIALIZABLE）或部分修复（RC）。
选择取决于泄漏的大小。

数据库的事务隔离级别有哪些？

我必须和你谈谈这件事。
几年前，我带领一个小团队在杭州搭建了一个电子系统，那是一个真正令人头疼的数据库问题。

记得有一次半夜，系统突然崩溃了。
我检查了日志，发现这是一个肮脏的教训。
当时用的是ReadUncommited。
想一想，一笔交易发生变化，另一笔交易直接读取未发布的数据，然后支付费用。
你觉得这很有趣吗？这架飞机真不好，信息一发出去，顾客就找上门来，老板急得翻墙了。
所以这个东西一般不用，危险性比较大。

后来改成了ReadCommited，这样就好多了。
脏读消失了，但是我们在做活动的时候，有两笔交易同时改变了优惠券的金额，而且一笔在读取的时候，另一笔正在提交，导致活动金额计算不正确。
但这种情况发生的不多，大部分情况下都很好，现在用的也居多。

此后，财务建议是他最需要的。
当时我们选择了RepeatableRead，但是遇到了重影的问题。
请求了报表，数据环境一样，第二次检查交易，结果和第一次不一样，因为中间插入了新数据。
这不可能。
在金融行业，这几乎是不可能的，所以最后我不得不使用Serialized。
虽然速度较慢，但​​更安全。
当时，约会迟到让我们很头疼，但这总比遇到问题要好。

因此，选择学位取决于使命。
对于一般事务等，ReadCommited 就足够了，而且结果是纯净的。
如果你处理的是金融、保险等，你就需要使用Serialized，你会慢慢认识它的。
这确实不仅仅是言语。
你不明白我为了这件事花了多少个夜晚，改变了多少个计划。

数据库中的隔离级别

结论： 1 、数据库隔离级别决定事务隔离程度，防止数据不一致。
2 .隔离级别：未提交读、提交读、可重复读、可串行化。
3 .未提交读：脏读风险，高性能。
4 、读固定：防止脏读，避免重复读风险。
5 、反复阅读。
防止脏读、不重复读和幻读的风险。
6 .可串行化：防止所有问题和性能不佳。
7 .脏读：读取未提交的事务数据。
8 、不重复阅读。
同一事务内读取的数据不一致。
9 、幻读：读取后数据行数发生变化。
1 0. 选择隔离级别需要权衡要求和性能。