答案是事务隔离级别决定可见数据版本而非仅控制读写权限：read committed每次select新建readview导致不可重复读；repeatable read事务首次select生成readview并复用，实现快照读一致性但幻读仍存；read uncommitted直接读最新版本致脏读；serializable则全量加锁严重降低并发。
因为事务隔离级别直接决定了你“能看到哪些版本的数据”，而不是简单地控制“能不能读别人改的”。InnoDB 用 MVCC 实现多数隔离级别，每个查询看到的数据快照，取决于它启动时生成的 Read View，而这个视图的构造规则，由当前事务的隔离级别决定。
READ-COMMITTED 下每次 SELECT 都生成新 Read View
同一个事务内，两次 SELECT 可能返回不同结果，因为第二次查询会重新生成 Read View，此时其他已提交事务的修改会被纳入可见范围。
- 典型现象：不可重复读 —— 第一次查 balance 是 1000，中间别人
UPDATE并COMMIT后，第二次查变成 900 - 适用场景：报表类、统计类任务，允许数据“随时间流动”，不强求事务内一致性
- 注意点：
UPDATE或DELETE语句仍基于语句开始时的快照（非事务开始时），所以可能“读到旧值，但更新了新值”
REPEATABLE-READ 下事务启动时固定 Read View
MySQL 默认级别。事务第一次执行 SELECT（或任何快照读）时生成 Read View，之后所有快照读都复用它，因此事务内看到的数据“冻结”在那一刻。
- 典型现象：避免不可重复读，但幻读仍可能发生（比如
INSERT新行被其他事务提交后，当前事务再次SELECT ... WHERE x > 100可能多出一行） - InnoDB 对幻读做了优化：普通
SELECT不加锁，但SELECT ... FOR UPDATE或INSERT会加间隙锁（gap lock）或 next-key lock，抑制插入 - 容易踩的坑：误以为“可重复读 = 完全无幻读”，其实只对快照读有效；当前读（如带锁读、DML）仍可能触发幻读，除非显式加锁或升级隔离级别
READ-UNCOMMITTED 和 SERIALIZABLE 的实际影响
这两个极端级别反而更容易判断行为，但生产环境极少用：
-
READ-UNCOMMITTED：不生成Read View，直接读最新行版本 —— 脏读必然发生。调试时偶尔用来验证是否真有未提交变更，但绝不用于业务逻辑 -
SERIALIZABLE：所有SELECT自动转成SELECT ... LOCK IN SHARE MODE，写操作会阻塞读，读操作也会阻塞写 —— 并发能力断崖式下降，QPS 常掉 50% 以上 - 特别注意：
SERIALIZABLE下即使没有显式加锁，SELECT也会等锁，容易引发隐式死锁，排查困难
MVCC 不是银弹，它让读不阻塞写，但“看到什么”完全取决于隔离级别和事务启动时机；很多线上数据不一致问题，根源不在 SQL 写错，而在没意识到当前事务的 Read View 已经“过期”或“太老”。
