MySQL事务隔离级别是数据库为解决并发事务间数据一致性问题而设计的核心机制，其核心作用是控制一个事务对另一个事务提交数据的可见性，平衡事务的一致性（ACID中的I，隔离性）与系统并发性能。MySQL共支持4种标准隔离级别（由低到高排序），默认隔离级别为「可重复读」，不同级别对应不同的并发问题解决方案，以下从核心概念、各级别详解、实操命令、注意事项等维度全面拆解。
一、核心前置概念
在理解隔离级别前，需先明确并发事务中常见的3类数据一致性问题（隔离级别本质就是解决这些问题），按影响程度从高到低排序：
脏读（Dirty Read）：一个事务读取到另一个事务未提交的数据。未提交的数据可能因事务回滚而失效，导致读取到“无效数据”，破坏数据准确性。
不可重复读（Non-Repeatable Read）：同一事务内，多次读取同一批数据，结果不一致。原因是两次读取之间，其他事务修改并提交了该批数据，破坏事务内数据的一致性。
幻读（Phantom Read）：同一事务内，多次执行相同的查询语句（如范围查询），返回的结果行数不一致。原因是两次查询之间，其他事务新增或删除了符合查询条件的数据，类似“出现了幻影数据”。
补充说明：隔离级别越高，对并发的限制越严格，能解决的并发问题越多，但系统性能损耗越大；反之，隔离级别越低，性能越好，但数据一致性风险越高。开发中需根据业务场景选择合适的隔离级别，而非盲目追求最高级别。
二、MySQL 4种事务隔离级别详解（重点）
MySQL支持的4种隔离级别完全遵循SQL标准，且针对默认级别（可重复读）做了专属优化，以下逐一详解，包含核心定义、解决的并发问题、存在的不足、适用场景及实操命令。
1. 读未提交（Read Uncommitted，最低隔离级别）
核心定义
一个事务可以读取到另一个事务尚未提交的修改数据，无需等待对方提交。这是隔离级别最低的一种，几乎没有隔离性可言。
并发问题处理
仅保证事务的原子性（要么全做，要么全不做），无法解决任何并发问题——脏读、不可重复读、幻读均会出现。
典型场景
极少在实际开发中使用，仅适用于对数据一致性要求极低、追求极致并发性能的临时场景，例如：临时统计系统的粗略数据（无需精准，仅需快速返回结果）、测试环境的临时数据查询。
实操命令
设置当前会话隔离级别：
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;验证：开启两个会话，会话1开启事务并修改数据（不提交），会话2可直接读取到未提交的数据。
2. 读已提交（Read Committed，常用普通级别）
核心定义
一个事务只能读取到另一个事务已经提交的修改数据，无法读取未提交的数据。这是大多数数据库（如Oracle、SQL Server）的默认隔离级别。
并发问题处理
解决了脏读（仅读取已提交数据，避免无效数据），但仍存在不可重复读、幻读。
示例：会话1开启事务，第一次读取数据为100；会话2开启事务，修改数据为200并提交；会话1再次读取同一数据，结果变为200，即“不可重复读”。
典型场景
适用于大多数普通业务场景，兼顾性能和基础数据一致性，例如：电商订单查询、用户信息展示、普通数据统计（无需事务内多次读取一致）、内容管理系统。
实操命令
设置当前会话隔离级别：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;验证：会话1未提交的修改，会话2无法读取；会话1提交后，会话2才能读取到最新数据。
3. 可重复读（Repeatable Read，MySQL 默认级别）
核心定义
同一事务内，多次读取同一批数据，结果始终保持一致（即便其他事务修改并提交了该数据）。这是MySQL的默认隔离级别，也是实际开发中最常用的级别。
MySQL专属优化
MySQL通过「MVCC（多版本并发控制）」机制对可重复读进行了优化：事务开启时，会生成一个“一致性视图”（快照），后续所有读取操作都基于这个快照，不受其他事务提交的影响。因此，MySQL的可重复读的实际效果优于SQL标准，能大幅减少幻读的出现（仅极端场景下会存在幻读）。
并发问题处理
解决了脏读、不可重复读，基本避免幻读（极端场景除外）。
极端幻读示例：会话1开启事务，查询“id>10”的所有数据（共5条）；会话2开启事务，新增一条id=11的数据并提交；会话1再次执行相同查询，仍返回5条数据（基于快照）；但会话1执行更新操作（如更新id>10的所有数据），会更新到6条数据（包含新增的id=11），此时再查询，会返回6条数据，即“幻读”。
典型场景
适用于绝大多数业务场景，尤其是对事务内数据一致性有要求、同时需要兼顾并发性能的场景，例如：金融对账、用户余额管理、订单创建与支付、数据批量处理。
实操命令
设置当前会话隔离级别：
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;验证：会话1开启事务后，会话2修改并提交的数据，会话1多次读取仍为初始快照数据；会话1提交后，才能读取到最新数据。
4. 串行化（Serializable，最高隔离级别）
核心定义
最高隔离级别，所有事务按顺序依次执行（类似单线程执行），不允许并发执行。事务执行时，会对涉及的表或行加锁，其他事务需等待当前事务完成后才能执行，完全杜绝所有并发问题。
并发问题处理
完全解决脏读、不可重复读、幻读，数据一致性达到最高，但并发性能最差。
注意：串行化会导致大量锁等待、超时，甚至死锁，仅在极端场景下使用。
典型场景
适用于对数据一致性要求极高、不考虑并发性能损耗的核心场景，例如：金融支付、资金转账、账务结算、核心业务的库存扣减（不允许任何数据不一致）。
实操命令
设置当前会话隔离级别：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;验证：会话1开启事务并操作数据（未提交），会话2执行相同表的操作会被阻塞，直至会话1提交或回滚。
三、4种隔离级别与并发问题对应表（核心汇总）
| 事务隔离级别 | 脏读 | 不可重复读 | 幻读 | 并发性能 | 适用场景 |
|---|---|---|---|---|---|
| 读未提交 | ✅ 存在 | ✅ 存在 | ✅ 存在 | 最高 | 临时粗略统计、测试环境 |
| 读已提交 | ❌ 不存在 | ✅ 存在 | ✅ 存在 | 较高 | 普通业务、订单查询、数据展示 |
| 可重复读（默认） | ❌ 不存在 | ❌ 不存在 | ⚠️ 极少存在 | 中等 | 绝大多数业务、金融对账、余额管理 |
| 串行化 | ❌ 不存在 | ❌ 不存在 | ❌ 不存在 | 最低 | 金融支付、资金转账、核心账务 |
四、实操常用命令（必记）
以下命令适用于MySQL 8.0及以上版本（5.7版本命令类似，仅变量名略有差异，如transaction_isolation可替换为tx_isolation），分为“查看”和“设置”两类，方便日常排查和配置。
1. 查看隔离级别
查看当前会话隔离级别（仅对当前连接有效）：
SELECT @@transaction_isolation;查看全局隔离级别（对所有新连接有效，不影响已存在的连接）：
SELECT @@global.transaction_isolation;
2. 设置隔离级别
设置当前会话隔离级别（临时生效，关闭连接后失效）：
SET TRANSACTION ISOLATION LEVEL 隔离级别名称;（如SET TRANSACTION ISOLATION LEVEL READ COMMITTED;）设置全局隔离级别（永久生效，需重启MySQL服务）：
SET GLOBAL TRANSACTION ISOLATION LEVEL 隔离级别名称;配置文件设置（永久生效，无需频繁执行命令）：修改MySQL配置文件（my.cnf/my.ini），添加
transaction-isolation=隔离级别名称（如transaction-isolation=REPEATABLE READ），保存后重启MySQL。
五、关键注意事项（避坑重点）
隔离级别与事务生效的区别：隔离级别不影响事务本身是否生效（如回滚、提交），仅影响并发事务间的数据可见性。很多开发者会将“隔离级别设置不当导致的数据不一致”误判为“事务不生效”，需注意区分。
默认级别不可随意修改：MySQL默认的“可重复读”已能满足绝大多数业务需求，除非有明确的业务场景（如金融支付），否则不建议修改为“串行化”（会严重影响性能），也不建议降低为“读未提交”（数据一致性无法保证）。
MVCC仅适用于InnoDB引擎：MySQL的MVCC机制（优化可重复读）仅对InnoDB引擎有效，MyISAM等非事务引擎不支持隔离级别，也不支持MVCC，需确保表使用InnoDB引擎。
全局隔离级别对已有连接无效：设置全局隔离级别后，仅对设置后新建立的数据库连接有效，已存在的连接仍使用之前的隔离级别，需重启连接或手动设置当前会话级别。
避免过度追求高隔离级别：高隔离级别意味着高锁开销、低并发，需根据业务优先级权衡——核心数据（资金、账务）用串行化，普通数据用读已提交/可重复读，临时数据用读未提交。
幻读的补充说明：MySQL的可重复读通过MVCC避免了大部分幻读，若需完全杜绝幻读，可使用串行化，或在查询时加行锁/表锁（如SELECT ... FOR UPDATE）。
六、总结
MySQL事务隔离级别的核心是“平衡一致性与并发性能”，4种级别各有适用场景，无需盲目追求最高级别。实际开发中，建议遵循以下原则：
无特殊需求，直接使用默认的“可重复读”，兼顾一致性和性能；
普通业务（如展示、查询），可使用“读已提交”，提升并发性能；
核心数据（如资金、账务），使用“串行化”，确保数据绝对一致；
临时统计、测试场景，可临时使用“读未提交”，追求极致性能。
同时，需牢记隔离级别的实操命令和避坑注意事项，避免因配置不当导致数据不一致，或因过度追求高隔离级别导致系统性能瓶颈。
