MySQL隔离级别是引擎层特性。MyISAM不支持事务,无事务日志、MVCC及行锁,仅提供表级锁,因此任何隔离级别设置均无效。InnoDB则通过MVCC、行锁和一致性视图实现四种隔离级别。
说实话,很多人一听到“MySQL隔离级别”,脑子里冒出的就是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE这一套,然后默认觉得只要执行了SET TRANSACTION ISOLATION LEVEL,数据库就能按设定工作。但一个常被忽略的坑是:MySQL隔离级别不是全局开关,而是引擎级别的特性。如果你的表用的是MyISAM,那这些隔离级别对你而言就是个摆设——哪怕语句执行成功,底层行为也纹丝不动。

长期稳定更新的攒劲资源: >>>点此立即查看<<<
先说结论:MyISAM 不支持事务,所以根本不存在「隔离级别」这个概念。MySQL 的隔离机制是引擎层实现的,而 MyISAM 在设计上就**不提供事务支持**——它没有事务日志(undo log / redo log)、没有一致性视图(consistent read view)、也没有 MVCC 机制。所有这些东西,都是 InnoDB 实现隔离级别的底层基石。
事务隔离的核心前提是什么?很简单:事务得能开始、能提交、能回滚。但 MyISAM 的所有写操作都是立即落盘的,没有 undo log。一旦 UPDATE 或 DELETE 执行,数据就不可逆地改了,没有任何反悔的余地。这意味着:
BEGIN 和 COMMIT 在 MyISAM 表上只是被忽略的空操作。SELECT 总是读最新物理数据,无法构造一致性视图。反过来看 InnoDB,它实现 REPEATABLE READ(默认级别)靠的是三件套:每个事务启动时生成一个 read view,记录当时活跃事务 ID 列表;通过 undo log 链回溯行的历史版本;配合 next-key lock 防止幻读。而 MyISAM 连最基本的行版本都没有,更不可能维护多版本数据或事务 ID 状态。你执行 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 对 MyISAM 表完全无效——语句能执行成功,但实际行为仍是无锁、无隔离、无并发控制的裸读写。
MyISAM 的并发控制可以说极其简单粗暴:
SELECT 加共享表锁(允许并发读)。INSERT/UPDATE/DELETE 加独占表锁(阻塞所有其他操作)。SELECT 同时执行,它们看到的数据也可能是不同时间点的——因为中间可能被另一个 UPDATE 全表覆盖。这种模型下,「隔离」只体现为「串行化写」,而不是事务意义上的「读写隔离」。所谓「可重复读」在 MyISAM 中根本无法保证:你在事务 A 里两次 SELECT,中间若被事务 B 的 UPDATE 插入,第二次结果必然不同。
不信?运行 SHOW ENGINES; 查看输出,你会看到这样一行:
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
其中 Transactions 列为 NO,XA 和 Sa vepoints 也都是 NO。这说明它连最基础的事务接口都没实现,更别说上层的隔离逻辑。
真正容易被忽略的一点是:很多人误以为「只要开了事务,隔离级别就有用」,但实际上,**MySQL隔离级别是否生效,取决于当前表使用的存储引擎**。哪怕你在同一个数据库里混合使用 InnoDB 和 MyISAM 表,对后者执行任何 SET TRANSACTION ISOLATION LEVEL 都不会改变其行为——它始终是「非事务性裸表」。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述