Skip to main content

ACID

数据库的ACID属性是事务管理的四个关键特性，确保数据库事务的可靠性。ACID代表原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。下面是对每个特性的详细解释：

原子性（Atomicity）​

原子性确保事务中的所有操作要么全部完成，要么全部不执行。事务是不可分割的最小工作单元。如果事务中的任何操作失败，整个事务都会回滚到事务开始之前的状态，就像这些操作从未发生过一样。这可以通过数据库的回滚（rollback）机制来实现。

一致性（Consistency）​

一致性确保事务从一个一致的状态转移到另一个一致的状态。这意味着数据库在事务开始之前和事务完成之后，都必须遵守所有的业务规则、完整性约束、索引和触发器等。如果事务违反了这些规则，整个事务将被回滚，数据库将保持之前的一致状态。

隔离性（Isolation）​

隔离性确保并发事务的执行不会互相干扰。事务应该独立于彼此运行，使得它们不能看到彼此的中间状态。数据库系统通常通过锁定对象来实现隔离性。根据隔离级别的不同（读未提交、读已提交、可重复读和串行化），一些隔离级别允许不同程度的数据可见性，因此可能会出现一些并发问题，如脏读、不可重复读和幻读。

持久性（Durability）​

持久性确保一旦事务被提交，它对数据库的改变就是永久性的。即使系统出现故障，如崩溃或电源故障，事务的效果也不会丢失。数据库通过将事务日志记录到非易失存储介质来实现持久性。

ACID属性是关系型数据库管理系统（RDBMS）的基石，它们使得数据库能够在出现故障或错误时保持数据的完整性和可靠性。然而，在分布式系统和某些NoSQL数据库中，可能会为了提高性能和可伸缩性而放宽ACID属性的一些要求，这通常是通过CAP定理和BASE（基本可用、软状态、最终一致性）原则来描述的。

隔离级别

数据库事务的隔离级别定义了一个事务在执行过程中可以看到其他事务所做更改的程度。这些隔离级别按照能够防止的并发问题的数量从最低到最高排序如下：

读未提交（Read Uncommitted）​

  • 描述：这是最低的隔离级别，在这个级别，一个事务可以看到其他事务未提交的更改。这意味着它允许脏读，即一个事务可以读取到另一个事务未提交的数据。
  • 问题：脏读、不可重复读、幻读。
  • 适用场景：只有在不太关心数据准确性的情况下使用，因为它可能会引起严重的并发问题。

读已提交（Read Committed）​

  • 描述：这个级别确保一个事务只能看到其他事务已经提交的更改。这可以通过在数据读取时使用共享锁来实现，当数据被读取时，其他事务不能修改它。
  • 问题：不可重复读、幻读。
  • 适用场景：这是许多数据库系统的默认隔离级别，因为它提供了一个平衡的并发性和数据准确性。

可重复读（Repeatable Read）​

  • 描述：在此级别下，一个事务在整个事务期间可以多次读取同一行，并且每次都会看到相同的数据。这通常是通过在涉及的数据上放置锁来实现的，防止其他事务对这些数据进行修改。
  • 问题：幻读。
  • 适用场景：适用于需要更高数据一致性的场景，但可能会牺牲一些并发性能。

串行化（Serializable）​

  • 描述：这是最高的隔离级别。在串行化隔离级别下，事务完全串行执行。这意味着一个事务在开始之前，必须等待其他事务完成，从而避免了所有的并发问题。
  • 问题：没有并发问题，但性能可能会受到影响。
  • 适用场景：适用于对数据一致性要求极高的场景，但并发性能可能会大大下降。

在实际应用中，选择哪种隔离级别通常是在数据一致性和系统性能之间进行权衡。较低的隔离级别（如读未提交和读已提交）可能会导致数据不一致的问题，但它们提供了更高的并发性能。而较高的隔离级别（如可重复读和串行化）提供了更好的数据一致性，但可能会降低系统的并发处理能力。数据库管理员或开发者需要根据具体的应用需求来选择最适合的隔离级别。

泛读

"泛读"这个术语在数据库领域并不常见，可能是一个误解或者翻译错误。在数据库的上下文中，通常讨论的是"幻读"（Phantom Read），这是一个特定的术语，指的是在数据库事务中出现的一种现象。

幻读（Phantom Read）​

幻读是指当一个事务重新执行一个查询时，会发现有其他事务插入或删除了满足查询条件的新行，导致两次查询结果不一致的现象。这种情况下，即使是相同的查询，也会返回一个之前不存在的“幻”行。

例如，假设有一个事务正在查询库存表中库存数量大于100的所有产品。在这个事务执行过程中，如果另一个事务插入了一个新的库存记录，其数量也大于100，并且提交了更改，那么当原事务再次执行相同的查询时，它将看到一个之前不存在的新行。这就是所谓的幻读。

幻读主要发生在隔离级别为可重复读（Repeatable Read）的情况下，因为尽管可重复读隔离级别可以防止非幻读的不可重复读问题，但它不能保证在一个事务执行期间不会有新的行被插入到表中。串行化（Serializable）隔离级别可以防止幻读，因为它通过锁定操作范围来确保事务是完全串行执行的。

如果您是指的另一个术语或概念，请提供更多的上下文或详细信息，这样我可以更准确地回答您的问题。

MVCC

MySQL中的多版本并发控制（MVCC）是InnoDB存储引擎用来提供高并发性能并实现非锁定读的一种机制。它允许多个事务同时对同一数据进行读取和修改，而不会互相干扰。MVCC在MySQL中的实现主要依赖于以下几个关键组件：

  1. 事务ID（Transaction ID）: 每个事务在开始时都会被分配一个唯一的事务ID，这个ID是单调递增的。它用于标识事务的版本号。

  2. 隐藏的版本字段: InnoDB在每行记录中都有两个隐藏的字段，一个用于存储行的创建版本号（事务ID），另一个用于存储行的删除版本号（事务ID）。创建版本号记录了哪个版本的事务创建了这一行，而删除版本号记录了哪个版本的事务删除了这一行。

  3. 回滚段（Undo Log）: 当事务对数据进行修改时，InnoDB会在回滚段中记录数据的旧版本。如果事务需要回滚或者其他事务需要访问旧版本的数据，InnoDB可以从回滚段中获取到。

  4. Read View: 当事务执行读操作时，InnoDB会为它创建一个“Read View”，这个视图定义了事务可以“看到”哪些版本的数据。Read View包含了活跃的事务ID列表，以及当前事务的ID。

MVCC工作流程大致如下：

  • 当事务要读取数据时，它将根据自己的Read View来确定哪些版本的数据是可见的。如果一行的创建版本号小于或等于事务的版本号，并且满足以下条件之一，则该行对事务是可见的：

    • 行的删除版本号未定义（即该行未被删除）。
    • 行的删除版本号大于事务的版本号（即该行在事务开始后被删除）。
    • 行的删除版本号对应的事务仍在Read View的活跃事务ID列表中。

  • 当事务要修改数据时，它将在回滚段中记录数据的旧版本，并更新行的创建或删除版本号，以反映这个事务的版本号。

通过上述机制，MVCC允许事务读取数据的一致性快照，而不需要对读取的数据加锁。这样，读写操作可以在不冲突的情况下并发执行，大大提高了数据库的并发性能。

需要注意的是，MVCC只在InnoDB存储引擎中提供，并且它的行为会根据事务的隔离级别有所不同。例如，在REPEATABLE READ隔离级别下，一个事务会看到在它开始时数据库的一致性快照，而在READ COMMITTED隔离级别下，每次查询都会生成一个新的Read View。

日志

在数据库系统中，特别是在MySQL的InnoDB存储引擎中，redo log（重做日志）和undo log（回滚日志）是两种关键的日志类型，它们用于确保事务的持久性和原子性，是实现事务ACID属性的重要组成部分。下面将详细解释这两种日志的实现和用法。

Redo Log（重做日志）​

Redo log是一种用于恢复操作的日志，它记录了事务对数据库所做的修改。在InnoDB中，redo log主要用于确保事务的持久性，即使在数据库系统发生崩溃的情况下也能保证已提交事务的修改不会丢失。

实现： InnoDB使用写前日志（write-ahead logging, WAL）的方法来实现redo log。在事务对数据进行修改时，这些修改首先被写入到redo log buffer中，然后在适当的时机，这些记录会被刷新到磁盘上的redo log文件中。这个过程称为日志刷新（log flushing）。当事务提交时，必须确保与该事务相关的所有redo log记录已经持久化到磁盘上，这个操作称为日志同步（log sync）。

用法： Redo log的主要用途是在数据库崩溃后进行恢复。当数据库重新启动时，它会检查redo log，找出所有已经记录但可能未完全写入数据文件的事务修改，然后重放（redo）这些操作，以确保这些事务的修改得到保留。

Undo Log（回滚日志）​

Undo log记录了事务所做的修改的逆向操作，它使得事务可以在执行过程中进行回滚，以及在并发控制中提供事务隔离性。

实现： 在InnoDB中，当事务对数据进行修改时，它会在undo log中记录一个反向操作。如果事务需要回滚，系统可以使用这些undo log记录来撤销之前的修改。Undo log记录通常存储在undo log segment中，这是InnoDB表空间的一部分。

用法： Undo log有两个主要用途：

  1. 事务回滚：如果事务遇到错误或接收到回滚命令，可以使用undo log来撤销已经执行的操作，确保事务不会对数据库造成影响。
  2. 多版本并发控制（MVCC）：在事务读取数据时，如果需要访问到被其他事务修改但尚未提交的数据版本，InnoDB可以使用undo log来构造出所需的旧版本数据，使得读取操作能够获取到一致性视图。

Redo Log与Undo Log的关系​

Redo log和undo log在事务处理中是互补的。Redo log确保了事务的持久性，即使系统崩溃，事务的影响也不会丢失。而undo log确保了事务的原子性，即事务要么完全执行，要么完全不执行，它也支持了MVCC中的非锁定读取。

在InnoDB中，redo log和undo log通常一起工作。例如，在事务提交之前，相关的redo log必须先被写入到磁盘中，而undo log则在事务执行过程中记录，以便在需要时回滚事务或为MVCC提供服务。此外，当系统进行垃圾回收（purge）操作，清理不再需要的undo log记录时，相关的redo log也会记录这一清理操作。