MySQL 事务隔离级别详解与实战

示例：设置当前会话为串行化

-- 设置当前会话隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 验证会话级别已变，但全局仍为 RR
SELECT @@global.tx_isolation; -- 输出 REPEATABLE-READ
SELECT @@session.tx_isolation; -- 输出 SERIALIZABLE

示例：设置全局隔离级别

-- 设置全局隔离级别
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

-- 验证全局级别已变
SELECT @@global.tx_isolation; -- 输出 READ-UNCOMMITTED

注意：如果设置后没有立即生效，请尝试关闭 MySQL 客户端并重新连接。

深入理解隔离级别带来的问题

读未提交与脏读

在读未提交级别下，一个事务在执行中，可以直接读到另一个事务未 commit 的更新数据。因为没有加锁保护，虽然效率高，但数据一致性极差，严重不建议采用。

-- 终端 A：设置隔离级别为读未提交
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

-- 重启客户端后验证
SELECT @@tx_isolation;

-- 开启事务并更新数据，但不提交
BEGIN;
UPDATE account SET blance = 123.0 WHERE id = 1;
-- 此时没有 commit

-- 终端 B：开启事务查询
BEGIN;
SELECT * FROM account;
-- 这里会读到终端 A 更新但未 commit 的数据（123.00），这就是脏读

读提交与不可重复读

在读提交级别下，一个事务 commit 后，另一个事务才能看到结果。但这会导致同一个事务内，多次读取同一条数据可能得到不同的值，即不可重复读。

-- 终端 A：设置隔离级别为读提交
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 开启事务并更新
BEGIN;
UPDATE account SET blance = 321.0 WHERE id = 1;

-- 终端 B：开启事务查询
BEGIN;
SELECT * FROM account;
-- 此时终端 A 尚未 commit，终端 B 读到旧值

-- 终端 A 提交
COMMIT;

-- 终端 B：再次查询
SELECT * FROM account;
-- 此时终端 B 读到了新的值（321.00），这就是不可重复读

不可重复读会带来什么后果？

假设小王负责将 Tom 的工资从 3200 改到 4500，而小张负责发放奖品。小张在查询工资表时，第一次查到了 3200（符合发奖条件），第二次查询时小王提交了事务，小张又查到了 4500（不符合发奖条件）。这种在同一事务内数据不一致的情况，显然会影响业务逻辑的正确性。

因此，虽然读提交比读未提交隔离级别高，但由于存在不可重复读的问题，我们也不推荐在生产环境中随意使用，除非业务能容忍这种数据波动。