MySQL高级讲座篇之：事务隔离级别详解：从底层实现看`REPEATABLE READ`的独特性。

大家好，我是你们的老朋友Bug终结者，今天咱们来聊聊MySQL事务隔离级别里那个有点神秘的家伙——REPEATABLE READ。

很多同学可能觉得，隔离级别嘛，不就是那几个单词吗？READ UNCOMMITTED，READ COMMITTED，REPEATABLE READ，SERIALIZABLE。背都能背下来。但你真的理解它们背后的原理，以及REPEATABLE READ的独特之处了吗？

别急着回答，咱们先从一个故事开始…

故事的开始：三个倒霉蛋的遭遇

假设我们有三个哥们儿：小明，小红，老王。他们都在访问同一个数据库，执行不同的操作。

• 小明： 负责统计商品总数
• 小红： 负责给特定商品涨价
• 老王： 负责下单购买商品

如果数据库没有事务隔离机制，或者隔离级别太低，这三个人之间就会互相干扰，产生各种奇奇怪怪的问题。比如：

• 脏读： 小红还没提交涨价操作，小明就读到了涨价后的商品数量，结果统计了个寂寞。
• 不可重复读： 小明第一次统计商品数量是100，小红涨价后提交了，小明第二次统计商品数量变成101，心态崩了啊！
• 幻读： 老王下了一单，小明统计发现多了个商品，这商品从哪儿冒出来的？

事务隔离级别的登场：不同程度的保护伞

为了解决这些问题，MySQL引入了事务隔离级别。不同的隔离级别就像是不同等级的保护伞，保护我们免受并发事务的干扰。

隔离级别	解决的问题	可能出现的问题	性能损耗
READ UNCOMMITTED	无	脏读，不可重复读，幻读	最低
READ COMMITTED	脏读	不可重复读，幻读	较低
REPEATABLE READ	脏读，不可重复读	幻读	中等
SERIALIZABLE	脏读，不可重复读，幻读	并发性能差	最高

可以看到，REPEATABLE READ级别已经相当不错了，它可以防止脏读和不可重复读。但是，它仍然存在幻读的问题。这正是我们今天要深入探讨的地方。

REPEATABLE READ的底层实现：MVCC的功劳

REPEATABLE READ之所以能实现“可重复读”，主要是靠一个叫做MVCC（Multi-Version Concurrency Control，多版本并发控制）的技术。

简单来说，MVCC就是为每一行数据维护多个版本，每个版本都对应一个事务。当一个事务开始时，它会看到一个“快照”版本的数据。在这个事务的整个生命周期内，它都只会看到这个快照版本的数据，即使其他事务修改了数据，它也不会受到影响。

举个栗子：MVCC的工作原理

假设我们有一张products表，其中有一行数据：

id | name   | price |
---|--------|-------|
1  | iPhone | 8000  |

现在，小明开启了一个事务，想要读取这条数据：

START TRANSACTION;
SELECT * FROM products WHERE id = 1;

MVCC会为小明的事务创建一个快照，假设这个快照的版本号是100。小明读取到的数据就是版本号为100的数据，也就是iPhone, 8000。

这时，小红也开启了一个事务，想要修改这条数据的价格：

START TRANSACTION;
UPDATE products SET price = 9000 WHERE id = 1;
COMMIT;

小红修改数据后，MVCC并不会直接覆盖原来的数据，而是创建一个新的版本，假设版本号是101，数据是iPhone, 9000。

现在，小明再次执行相同的查询：

SELECT * FROM products WHERE id = 1;

由于小明事务的快照版本号仍然是100，所以他读取到的数据仍然是iPhone, 8000。这就是“可重复读”的魅力！

代码示例：模拟MVCC

虽然我们不能直接在MySQL里“看到”MVCC的具体实现，但我们可以用代码来模拟一下它的工作原理：

class MVCCDatabase:
    def __init__(self):
        self.data = {}  # 存储数据，key是id，value是版本列表
        self.version = 0  # 当前版本号

    def get_data(self, id, version):
        """根据id和版本号获取数据"""
        if id not in self.data:
            return None

        versions = self.data[id]
        for v in reversed(versions): # 从最新版本开始查找
            if v['version'] <= version:
                return v['data']
        return None # 找不到小于等于指定版本的

    def update_data(self, id, new_data):
        """更新数据，创建新版本"""
        self.version += 1
        if id not in self.data:
            self.data[id] = []
        self.data[id].append({'version': self.version, 'data': new_data})
        return self.version

# 使用示例
db = MVCCDatabase()

# 初始数据
db.update_data(1, {'name': 'iPhone', 'price': 8000})

# 小明开启事务，快照版本号为2
xiaoming_version = 2
print(f"小明事务开始，版本号：{xiaoming_version}")
data_xiaoming_v1 = db.get_data(1, xiaoming_version)
print(f"小明第一次读取：{data_xiaoming_v1}")

# 小红修改数据
xiaohong_version = db.update_data(1, {'name': 'iPhone', 'price': 9000})
print(f"小红修改数据，版本号：{xiaohong_version}")

# 小明再次读取
data_xiaoming_v2 = db.get_data(1, xiaoming_version)
print(f"小明第二次读取：{data_xiaoming_v2}")

# 老王开启事务，快照版本号为4
laowang_version = 4
print(f"老王事务开始，版本号：{laowang_version}")
data_laowang = db.get_data(1, laowang_version)
print(f"老王读取：{data_laowang}")

# 小红回滚
# 在真实数据库中回滚会将版本4删除，这里简化模拟，实际上MVCC不会真正删除老的版本，而是进行标记
#假设要回滚到版本3之前的状态，需要找到小于等于3的最新版本
#如果回滚，需要重建索引，MVCC需要维护undo log。
#这里只是演示思想，实际实现复杂得多。

这段代码只是一个简单的MVCC模拟，它没有考虑并发控制、锁等等复杂的问题。但它可以帮助你理解MVCC的基本原理：每个事务都有自己的快照，读取数据时只会读取快照版本的数据。

REPEATABLE READ的局限：幻读的幽灵

虽然REPEATABLE READ可以防止脏读和不可重复读，但它仍然无法完全消除并发事务带来的问题。其中最常见的问题就是“幻读”。

什么是幻读？

幻读是指在一个事务中，两次执行相同的查询，第二次查询的结果集中出现了一些之前不存在的行，或者消失了一些之前存在的行。

幻读的产生：范围查询的陷阱

幻读通常发生在范围查询的场景下。比如：

• 小明想要统计products表中价格大于5000的商品数量。
• 在小明第一次统计之后，小红插入了一条价格为6000的新商品。
• 小明再次统计，发现数量变多了，就像出现了幻觉一样。

为什么MVCC无法解决幻读？

MVCC可以保证小明在事务期间读取到的每一行数据都是一致的。但是，它无法阻止其他事务插入新的数据。也就是说，MVCC只能保证“行级”的一致性，而无法保证“集合”的一致性。

代码示例：幻读的重现

假设我们有这样一段代码：

import pymysql

# 数据库连接信息
host = 'localhost'
port = 3306
user = 'root'
password = 'your_password' # 替换成你的密码
database = 'testdb' # 替换成你的数据库名

def execute_sql(sql, fetch=False):
    """执行SQL语句"""
    connection = None
    cursor = None
    try:
        connection = pymysql.connect(host=host, port=port, user=user, password=password, database=database, autocommit=False)
        cursor = connection.cursor()
        cursor.execute(sql)
        if fetch:
            return cursor.fetchall()
        connection.commit()
    except Exception as e:
        print(f"Error executing SQL: {e}")
        if connection:
            connection.rollback()
    finally:
        if cursor:
            cursor.close()
        if connection:
            connection.close()

# 创建 products 表
execute_sql("""
CREATE TABLE IF NOT EXISTS products (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(255),
    price INT
)
""")

# 清空 products 表
execute_sql("TRUNCATE TABLE products")

# 插入一些初始数据
execute_sql("INSERT INTO products (name, price) VALUES ('iPhone', 8000), ('Samsung', 7000)")

# 小明事务
def xiaoming_transaction():
    print("小明事务开始")
    execute_sql("START TRANSACTION")

    # 第一次统计
    count1 = execute_sql("SELECT COUNT(*) FROM products WHERE price > 5000", fetch=True)[0][0]
    print(f"小明第一次统计：{count1}")

    # 等待一段时间，模拟其他事务插入数据
    input("请按回车键模拟小红插入数据...")

    # 第二次统计
    count2 = execute_sql("SELECT COUNT(*) FROM products WHERE price > 5000", fetch=True)[0][0]
    print(f"小明第二次统计：{count2}")

    execute_sql("COMMIT")
    print("小明事务结束")

# 小红事务
def xiaohong_transaction():
    print("小红事务开始")
    execute_sql("START TRANSACTION")
    execute_sql("INSERT INTO products (name, price) VALUES ('Huawei', 6000)")
    execute_sql("COMMIT")
    print("小红事务结束")

# 主程序
if __name__ == "__main__":
    # 设置隔离级别为 REPEATABLE READ
    execute_sql("SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ")

    # 先运行小明事务
    import threading
    xiaoming_thread = threading.Thread(target=xiaoming_transaction)
    xiaoming_thread.start()

    # 等待小明事务开始并执行第一次统计
    import time
    time.sleep(1)

    # 运行小红事务
    xiaohong_thread = threading.Thread(target=xiaohong_transaction)
    xiaohong_thread.start()

    xiaoming_thread.join()
    xiaohong_thread.join()

运行这段代码，你会发现小明第一次统计的结果是2，小红插入数据后，小明第二次统计的结果变成了3。这就是幻读！

如何解决幻读？

要解决幻读，最简单粗暴的方法就是将隔离级别设置为SERIALIZABLE。SERIALIZABLE会强制事务串行执行，避免并发问题。但是，SERIALIZABLE的性能损耗非常大，通常不建议使用。

另一种方法是使用悲观锁或乐观锁。

• 悲观锁： 在查询时，使用SELECT ... FOR UPDATE语句锁定所有符合条件的行。这样可以防止其他事务插入新的数据。
• 乐观锁： 在表中增加一个版本号字段，每次更新数据时都增加版本号。在更新数据时，检查版本号是否与之前读取的版本号一致。如果不一致，说明数据已经被其他事务修改过，需要重新读取数据并重试。

REPEATABLE READ的独特性：平衡的艺术

REPEATABLE READ是MySQL的默认隔离级别，它在性能和隔离性之间做了一个很好的平衡。它既可以防止脏读和不可重复读，又能保持较高的并发性能。

虽然REPEATABLE READ存在幻读的问题，但在大多数情况下，幻读并不会造成严重的错误。只有在对数据一致性要求非常高的场景下，才需要考虑使用更高的隔离级别或锁机制。

总结：REPEATABLE READ，你值得拥有

REPEATABLE READ是MySQL事务隔离级别中的一位实力派选手。它凭借MVCC技术，在保证数据一致性的前提下，兼顾了并发性能。虽然它存在幻读的缺陷，但我们可以通过其他手段来解决。

希望通过今天的讲座，你对REPEATABLE READ有了更深入的理解。记住，理解底层原理才能更好地使用工具，才能在遇到问题时从容应对。

下次有机会，咱们再聊聊其他隔离级别，以及锁机制的实现原理。

感谢大家的收听！咱们下期再见！