READ COMMITTED 能阻止脏读，因其采用语句级快照机制：每次 SELECT 执行时仅读取该语句开始前已提交的数据，未提交的修改不纳入快照；需确保服务端全局、会话级和 ORM 框架三处配置一致且生效。
必须把隔离级别从 READ UNCOMMITTED 切到 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 用户注意：
sessionVariables设置 - Spring Boot 应用：在
application.yml中显式配置spring.datasource.hikari.connection-init-sql: SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，避免连接池复用旧会话
READ COMMITTED 下“像脏读”但其实不是脏读的坑
很多开发者反馈“明明设了 RC，还是读到了未提交数据”，大概率不是隔离级别问题，而是以下三类干扰：
- 应用层缓存没清：Redis 或 MyBatis 二级缓存中存了旧数据，数据库本身早就是干净的
- Navicat 等客户端连接未重连：已建立的连接不受新全局配置影响，必须断开重连才生效
- 代码里手动执行了
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，覆盖了默认设置，且未被发现
真正生效的关键点在于：每个连接启动时的隔离级别必须是 READ COMMITTED，而不是“某个地方配过就算”。线上环境最容易漏掉的是连接池初始化 SQL 和 ORM 框架的默认行为。
