READ COMMITTED能阻止脏读，因其采用语句级快照机制：每次SELECT执行时仅读取该语句开始前已提交的数据，未提交的修改不纳入快照。
READ UNCOMMITTED 是唯一允许脏读的隔离级别，线上必须禁用；提升到 READ COMMITTED（RC）能直接切断脏读路径，但要注意它不解决不可重复读和幻读。
为什么 READ COMMITTED 能阻止脏读
READ COMMITTED 的核心机制是「语句级快照」：每次 SELECT 执行时，MySQL 会基于当前已提交事务 ID 列表生成一个新快照，只读取在该语句开始前已 COMMIT 的数据。未提交的变更（哪怕已执行 INSERT 或 UPDATE）根本不会进入这个快照。
常见错误现象：SELECT * FROM orders 在后台导出时突然多出一笔“幻影订单”，而前端正卡在支付确认页没点提交——这基本就是隔离级别被设成了 READ UNCOMMITTED。
- RC 下，即使另一个事务只执行了
INSERT INTO users VALUES ('alice')但没COMMIT，你的SELECT就查不到 'alice' - RC 不加锁也不阻塞，性能比
REPEATABLE READ更轻量，适合读多写少、容忍不可重复读的场景（比如用户资料页的非关键字段） - 注意：RC 对
UPDATE ... WHERE和DELETE ... WHERE仍使用当前读（Current Read），会加行锁，这点和SELECT不同
如何安全地把隔离级别切到 READ COMMITTED
不能只改客户端连接参数，必须确认服务端全局配置、会话级设置、ORM 框架默认值三者一致，否则容易出现“以为切了，其实没生效”的情况。
- 检查当前会话级别：
SELECT @@transaction_isolation;，返回值应为'READ-COMMITTED'（MySQL 8.0+）或'READ-COMMITTED'（5.7 可能显示'READ-COMMITTED'或'READ-COMMITTED'） - 修改全局默认（需 SUPER 权限）：
SET GLOBAL transaction_isolation = 'READ-COMMITTED';，但该设置重启后失效；持久化要改my.cnf中的transaction_isolation = READ-COMMITTED - MyBatis 用户注意：
<transactionmanager type="JDBC"></transactionmanager>默认依赖 JDBC 驱动行为，需确认驱动版本 ≥ 5.1.47，否则可能忽略连接字符串中的sessionVariables设置 - Spring Boot 应用：在
application.yml中显式配置spring.datasource.hikari.connection-init-sql: SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，避免连接池复用旧会话
READ COMMITTED 下仍可能“像脏读”的坑
很多开发者反馈“明明设了 RC，还是读到了未提交数据”，大概率不是隔离级别问题，而是以下三类干扰：
- 应用层缓存没清：
Redis或 MyBatis 二级缓存中存了旧数据，数据库本身早就是干净的 - 代码绕过了事务：写了
set autocommit = 1或START TRANSACTION后忘记COMMIT，后续语句实际在自动提交模式下执行，每条都是独立事务 - 误用了
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE：这类语句在 RC 下会读取最新已提交版本并加锁，但若你本意只是普通查询，加锁反而暴露了不该暴露的数据边界
真正难处理的从来不是“怎么设成 RC”，而是确认所有数据链路——从连接建立、SQL 执行、结果返回、再到缓存落库——是否都严格遵循了这个级别。一个被 ORM 自动注入的 @Transactional 注解，可能因为 propagation 配置不当，让本该在 RC 下运行的逻辑悄悄退回到默认的 REPEATABLE READ。这种隐性降级，比明面上的配置错误更难排查。
