理解MySQL事务隔离：读未提交、读提交、可重复读和串行化

设置全局为读未提交：

SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

SELECT @@global.tx_isolation;   -- 输出 READ-UNCOMMITTED

如果没有立即生效，一般关闭客户端重连一下就好。

脏读与不可重复读实例

读未提交下的脏读

在读未提交级别，一个事务能读到另一个事务还未提交的更新。不加锁保护，效率高但数据一致性极差，强烈不建议使用。

打开两个终端，先确保隔离级别设为此级别。

-- 终端 A
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- 重连后验证
SELECT @@tx_isolation;

然后终端 A 开启事务但暂不提交：

BEGIN;
UPDATE account SET blance = 123.0 WHERE id = 1;
-- 没有 COMMIT

终端 B 在另一个事务里查询：

BEGIN;
SELECT * FROM account;
-- 此时会读到终端 A 未提交的 123.00，这就是脏读

读提交下的不可重复读

切换到读提交级别：

-- 终端 A
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 重连验证

终端 A 开启事务更新数据：

BEGIN;
UPDATE account SET blance = 321.0 WHERE id = 1;
-- 尚未提交

终端 B 第一次查询：

BEGIN;
SELECT * FROM account;
-- 此时读到旧值

终端 A 提交：

COMMIT;

终端 B 再次查询：

SELECT * FROM account;
-- 这次读到了 321.0，同一个事务里两次读取结果不同，即不可重复读。

这个不一致会带来实际问题。 比如小王负责把 Tom 的工资从 3200 改到 4500，小张负责根据工资发奖品。小张第一次查询看到 3200（符合发奖条件），但还没处理完，小王提交了更新，小张第二次查询看到 4500（不符合条件），导致业务判断出错。这种同一事务内的数据波动，往往是业务逻辑的 bug 源头。

因此，虽然读提交比读未提交看起来'高级'一些，但不可重复读的问题让它很少直接用于生产，除非业务明确能容忍这类不一致。大多数情况下，我们还是会用可重复读甚至串行化来保障数据稳定性。

选择隔离级别需要在并发性能和数据一致性之间做出权衡，没有绝对完美的方案。