数据库事务的四种隔离级别

MySQL提供了四种事务隔离级别：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。选择事务隔离级别需要根据实际情况来决定，下面是一些考虑因素：

并发性需求：读未提交级别会造成数据不一致的情况，而串行化级别会完全锁定表，因此通常情况下应该选择读已提交或可重复读级别，以兼顾并发性和数据准确性。

数据的业务特点：有些业务数据可能需要高度一致性，对数据一致性要求高的业务适合使用可重复读或串行化隔离级别。

事务的读写比例：事务的读写比例越大，可重复读级别的优势就越明显，因为可重复读级别可以避免不必要的锁定和读取。

应用的实际情况：不同的应用需要的隔离级别也不同，需要根据实际情况进行选择。

RR（可重复读）隔离级别的主要优点是可以避免幻读，即在一个事务中读取的所有行都保持不变，不受其他事务的干扰，这对于需要对数据进行多次读取和计算的场景非常有用，同时也可以提高数据的一致性。

使用RR隔离级别的场景包括：

需要多次读取同一批数据进行计算的场景，例如统计分析类应用。

对于多表关联查询，如果查询中包含的表中有新增、删除、更新操作，则需要使用RR隔离级别，否则会出现幻读。

需要注意的是，RR隔离级别会引入一些不必要的锁定和读取，可能会影响并发性能，因此需要根据具体情况进行选择。

题主所学的这些都是事务的实现，undo日志和redo日志本质是事务回滚时底层的机制，和事务隔离级别都没有关系。
事务隔离级别，四个
NONE：没有
READ_COMMITED：在事务开启之前，只读取已提交事务的数据，不读取未提交的事务。
REPEATABLE：可重复读，指一个事务在进行两次查询时得到的结果不一样，因为在这个事务执行期间，其他事务可能删除或者插入了满足条件的查询记录。
Serializable：事务串联化，对某一个表的读事务或写事务，只能依次执行。
底层实现，通常都是读锁和写锁。默认情况下都是只允许一个写锁和多个读锁。而且即使是写锁，也希望是乐观锁，采用CAS技术，最大的提高并发性能。所以Serializable基本不现实，和NONE一样，只存在于理论中。
REPETABLE为什么不使用，是因为有更好的解决办法，例如只允许你查询前一天的数据，不是实时计算，那么这个问题就不会存在了，这样你就能理解为什么许多统计信息，都是T-1的数据，都是前一天的数据，不会计算当天的数据。