MySQL的ACID、死锁、MVCC问题

news2024/10/7 16:26:44

1 ACID

ACID代表原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。一个确保数据安全的事务处理系统，必须满足这些密切相关的标准。

原子性： 一个事务必须被视为一个不可分割的工作单元，整个事务中的操作要么全部提交成功，要么全部失败回滚。对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。
一致性： 数据库总是从一个一致性状态转换到下一个一致性状态。如果事务最终没有提交，该事务所做的任何修改都不会被保存到数据库中。
隔离性： 通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的，这就是隔离性带来的结果。
持久性： 一旦提交，事务所做的修改就会被永久保存到数据库中。此时即使系统崩溃，数据也不会丢失。持久性是一个有点模糊的概念，实际上持久性也分很多不同的级别。有些持久性策略能够提供非常强的安全保障，而有些则未必。而且不可能有100%的持久性保障。（如果数据库本身能做到真正的持久性，那么备份又怎么能增加持久性呢？）
ACID事务和InnoDB引擎提供的保证是MySQL中最强大、最成熟的特性之一。虽然它们在吞吐量方面做了一定的权衡，但如果应用得当，就可以避免在应用层实现大量复杂逻辑。

2 死锁

死锁是指两个或多个事务互相持有和请求相同资源的锁，产生了循环依赖。当多个事务试图以不同的顺序锁定资源时会导致死锁。当多个事务锁定相同资源时，也可能会发生死锁。例如下述例子的两个事务因试图以不同顺序访问资源时会导致死锁。

# 事务1
begin
update stock_price set close = 45.50 where stock_id = 4 and date = '2020-05-01';
update stock_price set close = 19.80 where stock_id = 3 and date = '2020-05-02';
end;
# 事务2
begin
update stock_price set close = 20.12 where stock_id = 3 and date = '2020-05-02';
update stock_price set close = 47.20 where stock_id = 4 and date = '2020-05-01';
end;

        为了解决这个问题，数据库系统实现了各种死锁检测和锁超时机制。更复杂的系统，比如InnoDB存储引擎，检测到循环依赖后会立即返回一个错误信息。这可能是一件好事——否则，死锁将表现为非常缓慢的查询。还有一种方式，当超过锁等待超时时间限制直接终止查询，这样做通常来说不太好。InnoDB目前处理死锁的方式是将持有最少行级排他锁的事务回滚（这是一种最容易回滚的近似算法）。
        锁的行为和顺序是和存储引擎相关的。同样的一系列查询语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的。
        一旦发生死锁，如果不回滚其中一个事务（部分或全部），就无法打破死锁。对于事务型的系统，这是无法避免的，所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需重新从头开始执行被回滚的事务即可，除非又遇到另一个死锁。

3 多版本并发控制（MVCC）

        MySQL的大多数事务型存储引擎用的都不是简单的行级锁机制。它们会将行级锁和可以提高并发性能的多版本并发控制（MVCC）技术结合使用。不仅是MySQL，包括Oracle、PostgreSQL以及其他一些数据库系统也都使用了MVCC，但各自的实现机制不尽相同，因为MVCC如何工作没有统一的标准。
        可以认为MVCC是一个行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。根据其实现方式，不仅实现了非阻塞的读操作，写操作也只能锁定必要的行。
        MVCC的工作原理是使用数据在某个时间点的快照来实现的。这意味着，无论事务运行多长时间，都可以看作数据的一致性视图，也意味着不同的事务可以在同一时间看到同一张表中的不同数据。
        每个存储引擎实现MVCC的方式都不同。其中一些变体包括乐观并发控制和悲观并发控制。可以通过序列图解释一下InnoDB的行为，以此来展示MVCC的一种实现方式。
跨不同事务处理同一行多个版本的序列图
        InnoDB通过为每个事务在启动时分配一个事务ID来实现MVCC。该ID在事务首次读取任何数据时分配。在该事务中修改记录时，将向Undo日志写入一条说明如何恢复该更改的Undo记录，并且事务的回滚指针指向该Undo日志记录。这就是事务如何在需要时执行回滚的方法。
        当不同的会话读取聚簇主键索引记录时，InnoDB会将该记录的事务ID与该会话的读取视图进行比较。如果当前状态下的记录不应可见（更改它的事务尚未提交），那么Undo日志记录将被跟踪并应用，直到会话达到一个符合可见条件的事务ID。这个过程可以一直循环到完全删除这一行的Undo记录，然后向读取视图发出这一行不存在的信号。
        事务中的记录可以通过在记录的“info flags”中设置“deleted”位来删除。这在Undo日志中也被作为“删除标记”进行跟踪。
        值得注意的是，所有Undo日志写入也都会写入Redo日志，因为Undo日志写入是服务器崩溃恢复过程的一部分，并且是事务性的。这些Redo日志和Undo日志的大小也是高并发事务工作机制中的重要影响因素。
        在记录中保留这些额外的信息带来的结果是，大多数读取查询都不需要额外获取锁。他们只是尽可能快的读取数据，确保仅查询符合条件的行即可。缺点是存储引擎必须在每一行中存储更多的数据，在检查行时需要做更多的工作，并处理一些额外的内部操作。
        MVCC仅使用REPEATABLE READ和READ COMMITTED隔离级别。READ UNCOMMITTED与MVCC不兼容，是因为查询不会读取适合其事务版本的行版本，而是不管怎样都读最新版本。SERIALIZABLE和MVCC也不兼容，是因为读取会锁定他们返回的每一行。