深入解析MySQL的事务隔离及其对性能的影响
SQL标准定义了4类隔离级别，包括一些特定的规则来限制事务内外可见的变化以及不可见的变化，而低级别隔离级别通常支持更高的并发处理，并且具有较低的系统开销。读未提交（读未提交内容）
在这种隔离级别，所有事务都可以看到其他未提交事务的执行结果。这种隔离级别很少用于实际应用程序，因为它不比其他级别执行得更好。
读取提交（读取提交）
这是大多数数据库系统的默认隔离级别（而不是MySQL默认）。它满足隔离的简单定义：一个事务只能看到被致力于公司的变化。该隔离级别也支持所谓的不可重复读。因为同一事务的其他实例在实例处理过程中可能有新的提交，因此相同的选择可能返回不同的结果。
可重复读（重读）
这是MySQL默认的事务隔离级别，使同一事务的多个实例可以看到同样的数据行时，读取数据的同时，但在理论上，这可能会导致另一个棘手的问题：幻读。简单地说，幻读，当用户读取一系列的数据行，另一个交易中插入新的一行，范围。当用户读取数据行了，会有新的幻像行。InnoDB和Falcon存储引擎已经解决了这个问题，通过多版本并发控制（MVCC，多版本并发控制）机制。
序列化（序列化）
这是最高级别的隔离，这使得通过强制事务解决幻象问题不可能相互冲突。简而言之，它是每个读取数据线上的共享锁。在这个级别上，它可能导致大量超时现象和锁竞争。
这四个隔离级别是用不同的锁类型实现的。如果读取相同的数据，则很容易出现问题：
脏读（脏读）：一个事务更新了数据，另一个事务读取相同的数据，此时。由于某些原因，前一次回滚操作、后一个办公室读取的数据将不正确。
不可重复读不可重复。在事务的两个查询中，数据不一致。这可能是两个查询过程，其中插入事务更新原始数据。
（幽灵读取）幻像读取：在两个查询中，事务数据中的数目不一致，如事务查询数列（行）数据和另一个事务，但此时，一些新数据进入列，前一个事务在下一个查询中，您会发现几个列的数据是它以前没有的。
在MySQL中，这四个隔离级别被实现，并且有可能出现的问题如下所示：
MySQL事务隔离级别对其性能的影响
MySQL的默认工作在三级。我们知道事务隔离是避免数据以避免并发操作的交互一致性。为了保证数据的一致性，介绍了事务隔离功能，四级以上的数据一致性保护逐渐提高。4级交易的最佳分离效果，但它的性能最差，一般不用于生产环境。
下面的例子是用来在不同层次的MySQL性能影响的试验。我的实验环境是：redhat5.8 + mysql5.5
首先，我们启用了两个会话：
1。验证级1的特性
我们在会话A上做的操作是：
会话B的操作与会话A相同，该会话不再附加到屏幕截图上。
接下来，我们会观察到一系列实验来看看read-uncommitted是什么，它的特点和它如何影响我们的工作。首先，我们可以看到表中的初始数据如下：
然后我们换一对会议的记录，并有如下变化：
注意：我们已经启用了它上的事务，但这里不执行提交操作。
我们下一步做选择查询，已经改变了sessionb表，结果如下：
我们可以清楚地看到，虽然我们没有对会议的结果犯，结果发生了变化。因此，在这个层面上，未提交的操作对数据的一致性的影响。因此，如果我们在会议上的回滚操作，我们会发现会话B对结果回到原来的结果，这将导致数据的不一致性，这也被称为幻读数据的现象，看起来很奇怪的事情。因此，在某些情况下，我们应该避免这种现象的出现，但是这一水平没有应用。例如，当我们有大量的数据写入和很少的读操作时，它适合这种模式。
您可以看到，在会话回滚之后，会话B中的数据变成了原来的样子，也称为幻像读取：
2。验证级别读取提交特性
首先，会话和会话的隔离级别更改为read-committed，和交易都是打开的，和操作如下：
接下来，我们看一下导师表的初始状态信息：
然后我们还在更新数据，目前还没有提交更新后，我们可以看到，在会议的结果已经改变了：
在这一点上，我们查看会话B并发现结果保持不变。
然而，如果我们在会议上提交操作，在这个时候，我们会发现，sessionb会在这个时候更改查询，这也导致了数据的不一致，也是一个神奇的读数据。
三.读数据
数据是可读的，也被称为repeatable-read，这是MySQL的默认的事务隔离级别。它有它的优点，但它并不能从根本上解决数据一致性问题。首先，让我们来测试MySQL在这个级别上的工作方式，什么特点，以及我们应该怎么做。
我们建立repeatable-read第一环境，具体的操作方法如下：
然后我们看一下最初的数据，结果如下：
我们在会话A中修改数据并进行提交，修改后的结果如下：
然后我们查看会话B，发现仍然没有变化：
这是可读性的属性。只要会话不提交，但对方修改，但结果仍然是不变的，只有提交操作是在会话B进行，改造将在sessionb生效。
4、seriabliable
这个级别在事务隔离安全性中是最好的，但也是最差的性能，因为在这个级别上的所有操作都是串行执行的。一个操作未提交，另一个受影响的操作处于阻塞状态。
为了验证这种效果，我们设置了环境，该环境与会话A和会话B同时设置，如下所示：
任何一场会议修改并没有提交操作进行。在这一点上，发现sessionb查询操作始终处于阻塞状态。
这是串行隔离的结果，也是并发隔离中串行化差的原因。