解锁MySQL事务的奥秘：深度揭秘MySQL事务机制

在使用数据库的过程中，事务通常是我们一个很熟悉的概念。

事务的主要目标是确保一组数据库操作全部成功或全部失败。

在MySQL中，事务支持是在存储引擎级别实现的。

需要注意的是，MySQL 是一个支持多种存储引擎的系统，但并非所有引擎都提供事务支持。例如，MySQL原生的MyISAM存储引擎不支持事务，这也是InnoDB取代MyISAM的重要原因之一。

在这篇文章中，将以InnoDB为例，深入研究MySQL对事务支持的具体实现，并根据这些原则提供实用的建议。希望这些案例研究能够加深您对MySQL事务原理的理解。

隔离性

当提到事务时，ACID（原子性、一致性、隔离性、持久性）肯定是我们首先想到的一个术语。今天，我们将深入研究其中一个方面，即ACID的Isolation隔离性。

当多个事务在数据库上同时运行时，可能会导致诸如脏读，不可重复读和幻读之类的问题。

为了解决这些问题，引入了隔离级别的概念。

我们要清楚的是，隔离级别越高，执行效率就越低。因此，很多时候我们需要在两者之间取得平衡。

SQL标准定义了四种事务隔离级别：

• 读未提交：事务提交之前，它所做的更改对于其他事务是可见的。
• 已提交读：提交事务后，它所做的更改对其他事务可见。
• 可重复读：事务执行期间看到的数据与事务启动时最初看到的数据保持一致。在Repeatable Read隔离级别中，未提交的更改对于其他事务也是不可见的。
• Serialized：顾名思义，对于同一行记录，"写"操作会加一个"写锁"，"读"操作会加一个"读锁"。如果读锁和写锁之间发生冲突，稍后尝试访问的事务必须等待前一个事务完成才能继续。

已提交读 和可重复读的隔离级别确实有点难以掌握。

示例

为了帮助说明这些隔离级别，让我们考虑一个示例。假设我们有一个数据表 T，只有一列和一行包含值1。

mysql > create table test_table(id int ) engine = InnoDB; 

mysql > insert test_table(id) values ( 1 ) ;

以下是按时间顺序执行的两个事务的行为：

现在我们看看在不同隔离级别下会产生的不同结果，以及场景中V1、V2和 V3的值是什么。

• 未提交读： V1的值是2。在这种情况下，即使事务 2 尚未提交，事务1也能看到事务2更新后的结果。因此，V2 和 V3 也都是 2。
• 已提交读： V1是1，V2是2 。 事务 2 的更新仅在提交后对事务 1 可见。因此，V3的值也是2。
• 可重复读：V1和V2都是1，但V3是2。V2是1的原因是为了满足事务执行过程中看到的数据必须从头到尾保持一致的要求
• 串行化：当事务 2 尝试将值更新为 2 时，它将被锁定。它只能在事务 1 提交后才能继续。因此，从事务1的角度来看，V1和V2的值为1，而V3的值为2。

在实现上，数据库创建一个视图，访问是基于这个视图的逻辑结果。

在可重复读隔离级别中，该视图在事务开始时创建，并在整个事务中使用。

在读已提交隔离级别中，此视图是在每个 SQL 语句执行开始时创建的。

值得注意的是，读未提交 隔离级别直接返回记录上的最新值，没有视图的概念，而序列化隔离级别则采用锁定来直接防止并发访问。

很明显，不同隔离级别下的数据库行为有所不同。事实上，Oracle 的默认隔离级别是已提交读。 因此，对于从Oracle 迁移到MySQL 的应用程序来说，MySQL为了保持数据库隔离级别的一致性，必须记住将 MySQL 的隔离级别设置为"已提交读"。

事务隔离的实现 现在我们了解了事务隔离级别，让我们仔细看看事务隔离是如何实现的。

我们先深入研究可重复读隔离级别的细节。

在MySQL中，实际上，每条记录在更新时都伴随有一条回滚记录。可以通过使用此回滚记录访问先前的状态来获取记录上的最新值。

假设某个值依次从1过渡到2、3、4。在回滚日志中，您会发现类似以下的记录：

当前值为4，但是查询这条记录时，不同时间开始的事务会有不同的read-views。

如图所示，在read-views 1、2 和 3中，该记录的值分别为1、2和4。同一条记录在系统中可以有多个版本，这称为多版本并发控制（MVCC）。

Read-View 1如果想获取 value 1，必须按顺序执行 图中所示的所有回滚操作。

此外，即使当前有另一个事务更改4为5，该事务也不会与与读取视图 1、2 和 3 关联的事务发生冲突。

您可能想知道回滚日志何时被删除，因为它们不能无限期地保留。答案是当不再需要它们时将其删除。

换句话说，当没有事务需要访问回滚日志时，系统将确定可以删除它们。

什么时候不再需要它们？当系统中没有早于回滚日志的读取视图时会将他们删除。

基于上面提供的解释，我们来讨论一下为什么建议尽可能避免长时间运行的事务。

长时间运行的事务会导致系统中出现非常多旧的事务视图。由于这些事务可以随时访问数据库中的任何数据，因此它们可能需要的所有回滚记录都必须保留在数据库中，直到事务提交为止。这反过来又导致大量的存储空间消耗。

在 MySQL 5.5 之前的版本中，回滚日志与数据字典一起存储在 ibdata 文件中。即使长时间运行的事务最终提交并且回滚段被清除，文件大小也不会减少。

长时间运行的事务还会占用锁资源，并有可能影响整个数据库的性能。

开启事务的方式

如前所述，长时间运行的交易存在潜在风险，因此强烈建议尽可能避免它们。

在许多情况下，开发人员并没有故意使用长时间运行的事务；通常，这是由于误用造成的。

MySQL提供了几种发起事务的方式：

• BEGIN使用语句或显式启动事务START TRANSACTION。提交和回滚对应的语句是COMMIT和ROLLBACK。
• using SET AUTOCOMMIT=0是一个禁用当前线程自动提交的命令。这意味着如果您只执行一条 SELECT 语句，则会启动一个事务，并且不会自动提交。此事务将持续存在，直到您主动执行COMMITorROLLBACK语句或与数据库断开连接。

SET AUTOCOMMIT=0某些客户端连接框架可能会在连接成功后默认执行命令。

这会导致后续查询位于事务内，如果连接长时间保持打开状态，则可能会导致意外的长时间运行事务。

因此，建议通过语句SET AUTOCOMMIT=1显式使用和启动事务。