1.事务的特性（ACID）

事务（Transaction）是指一组操作被看作是一个不可分割的工作单元，这组操作要么全部执行成功，要么全部执行失败。事务的特性通常用 ACID 四个单词来描述，它们分别代表原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

• 原子性：事务是一个原子操作，它要么全部完成，要么全部不完成，不会出现部分完成的情况。如果在事务执行过程中出现了错误，所有的修改将会被回滚（Rollback）到事务开始前的状态，不会对数据产生影响。
• 一致性：在事务开始和结束时，数据库都必须保持一致性状态。事务开始前和结束后，数据库的完整性约束没有被破坏，所有的数据都应该合法。
• 隔离性：多个事务之间的操作是相互隔离的，每个事务都感觉不到其他事务的存在。隔离级别可以通过设置来控制事务的隔离程度，例如读未提交、读已提交、可重复读和串行化等级别。
• 持久性：事务完成后，对于数据的修改应该永久保存在数据库中，即使系统故障或者断电等异常情况也不应该丢失。

2.事务的隔离级别

事务隔离级别是指多个事务之间的隔离程度，它决定了一个事务在修改数据时对其他事务的影响以及读取数据时能够看到其他事务的哪些修改。

MySQL 支持四种标准的隔离级别，分别是：

1. 读未提交（Read Uncommitted）：允许脏读，一个事务可以读取到另一个未提交的事务修改的数据，会出现幻读、不可重复读和脏读等问题。

2. 读提交（Read Committed）：只能读取到已经提交的数据，但是在同一个事务中，多次读取同一数据，可能会得到不同的结果，也会出现幻读问题。

3. 可重复读（Repeatable Read）：保证了同一个事务中多次读取同一数据结果相同，但是在事务执行过程中，会出现新插入的数据无法读取到的问题，即幻读问题。

4. 串行化（Serializable）：强制事务串行执行，避免了脏读、不可重复读和幻读问题，但是会大大降低数据库的并发性能。

在实际应用中，应根据业务的特点和数据的一致性需求选择合适的隔离级别。一般情况下，推荐使用可重复读隔离级别。

隔离级别	脏读	不可重复读	幻读
READ-UNCOMMITTED	√	√	√
READ-COMMITTED	×	√	√
REPEATABLE-READ	×	×	√
SERIALIZABLE	×	×	×

3.一致性视图（read-view）

InnoDB通过构造一致性视图来实现RC和RR隔离级别。在RC和RR隔离级别下，事务只能看到在启动该事务时已经提交的数据，也就是说只能看到在该事务启动瞬间，对事务的隔离级别所允许的操作已经完成的数据。为了实现这一点，InnoDB使用了一致性视图机制，通过保存当前活跃事务的ID和启动瞬间已提交的事务ID构建一致性视图，然后在查询时使用该视图来确定可见的数据版本。因此，使用一致性视图机制，InnoDB可以提供高效的RC和RR隔离级别实现。

4.事务隔离是如何实现的 ？

在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。

5.回滚日志什么时候会被删除？

系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除。

具体来说，当一个事务提交时，如果当前系统中没有其他事务需要使用该事务的回滚日志，则该事务的回滚日志就可以被删除。如果还有其他事务需要使用该事务的回滚日志，则该回滚日志会被保留，直到所有依赖该回滚日志的事务都提交或者回滚。

6.为什么尽量不要使用长事务?

长事务在数据库中长时间占用锁资源，会导致锁等待和死锁等问题，影响系统的并发性能和稳定性。

具体来说，长事务会对回滚日志和MVCC机制造成影响。在数据库中，每个事务都有一个唯一的事务 ID，每次更新操作都会在回滚日志中记录一条对应的回滚操作，用于在事务回滚时恢复数据的一致性。而长事务会使得回滚日志中的回滚操作不断累积，占用大量磁盘空间。同时，长事务中的事务视图也会一直存在，这会使得数据库中的版本链表越来越长，导致查询时的性能下降。

另外，长事务还会增加数据库的故障恢复成本。当数据库出现故障需要恢复时，如果存在长事务，那么需要将这些长事务中所有的操作都回滚，这会导致恢复时间变长。

因此，尽量不要使用长事务，可以将事务尽早提交或者分成多个较短的事务来完成操作。

7.事务是如何实现的MVCC呢? 

事务的实现基于多版本并发控制（MVCC）的机制。在 InnoDB 存储引擎中，每个行都有一个隐藏的字段，用于存储行的创建时间和删除时间，这个字段的名称是 transaction_id。当行被更新或删除时，事务会将一个新的版本写入磁盘，但原来的版本并不会被删除，而是标记为已删除，同时为这个新版本分配一个新的 transaction_id。

在事务开始之前，会为该事务分配一个唯一的事务 ID（transaction_id），同时会记录一个 up_limit_id，表示在当前事务开始之前，已经提交的最大事务 ID。在快照读中，事务会创建一个视图，用于保存当前事务在执行快照读时数据库的状态，这个视图也称为一致性视图（consistent read view）。这个视图是根据当前事务的 transaction_id 和 up_limit_id 计算出来的，它定义了当前事务能够看到哪些行的版本。

在执行快照读时，如果行的 transaction_id 小于等于当前事务的 up_limit_id，那么这行的版本是可见的。否则，这行的版本是不可见的。通过这种机制，InnoDB 实现了快照读。

在当前读中，事务会获取一个共享锁或排它锁来锁定要修改的行，这样其他事务就不能同时修改这行。在当前读时，如果一个行的 transaction_id 大于当前事务的 up_limit_id，那么该行的最新版本需要被读取并加锁，以保证在这个事务内看到的是最新的版本。为了避免幻读，InnoDB 使用了间隙锁（gap lock）来锁定一定范围内的行，从而保证事务内看到的是连续的一段数据。

总之，事务在 InnoDB 中实现了多版本并发控制（MVCC）的机制，通过记录每个行的创建时间和删除时间，以及每个事务的 transaction_id 和 up_limit_id 来实现快照读和当前读。

8.什么是快照读和当前读

快照读（Snapshot Read）是指在读取数据的过程中，不会对数据的修改产生干扰。通常使用MVCC（多版本并发控制）来实现，即读取数据库中某一时刻的快照，而不受其他并发事务的影响。

在InnoDB中，快照读通常使用SELECT语句进行，其实现方式是通过在一致性视图（Consistent Read View）中找到符合条件的数据行版本。而一致性视图是事务启动时创建的，包含了所有已提交的事务和未提交的当前事务。在快照读期间，如果其他事务对数据行进行了修改，那么读取的数据行版本将不会受到影响。

当前读（Current Read）是指在读取数据的过程中，同时对数据进行修改，也就是读取并锁定了数据行，确保其他并发事务无法修改该数据行。当前读通常使用SELECT...FOR UPDATE或SELECT...FOR SHARE语句进行，其中SELECT...FOR UPDATE会对选中的数据行进行加锁，SELECT...FOR SHARE则会对选中的数据行进行共享锁。

当前读与快照读的区别在于当前读会锁定数据行，因此可能会阻塞其他并发事务，而快照读则不会锁定数据行，不会产生阻塞。选择使用哪种读取方式应该根据实际业务需求和数据访问模式来决定。

9.为什么rr能实现可重复读而rc不能

分两种情况

(1)快照读的情况下,rr不能更新事务内的up_limit_id,
而rc每次会把up_limit_id更新为快照读之前最新已提交事务的transaction id,则rc不能可重复读
(2)当前读的情况下,就是读的时候加锁，保证是最新版本,rr是利用record lock+gap lock来实现的,而rc没有gap,所以rc不能可重复读