MySQL的REPEATABLE READ在InnoDB中通过Next-Key Lock解决幻读，但Python Web应用因自动提交、事务边界不清或ORM行为导致快照读失效，需显式控制事务和当前读。
MySQL 默认的 REPEATABLE READ 隔离级别在 InnoDB 中已通过 Next-Key Lock 解决了大部分幻读，但 Python Web 应用中仍可能因显式快照读、长事务或 ORM 自动提交行为暴露幻读现象——这不是隔离级别失效，而是你没触发它的保护机制。
为什么 Django/Flask 里还是看到幻读？
Python Web 框架常默认启用自动提交（AUTOCOMMIT=1），导致每个查询都是独立事务，REPEATABLE READ 的“一致性视图”根本没建立起来。比如：
- Django 的
select_related()或原生cursor.execute("SELECT ...")在非事务块中执行 → 每次都是新快照，两次查询之间插入的新行自然可见 - Flask-SQLAlchemy 默认
autocommit=False，但若没显式db.session.begin()或用@app.before_request开启事务，实际仍是语句级事务 - 异步 Web 框架（如 FastAPI + asyncpg）若混用同步 MySQL 驱动（如 PyMySQL），事务上下文极易丢失
用 SELECT ... FOR UPDATE 锁住范围，但要注意场景
当业务逻辑明确需要“查-判-改”原子性（例如库存扣减、防重复下单），不能依赖 MVCC 快照，必须升级为当前读并加锁：
- 在事务内执行
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE，InnoDB 会加Next-Key Lock（行锁 + 间隙锁），阻止其他事务在此范围插入新 pending 订单 - 避免在
READ COMMITTED下用FOR UPDATE：它只锁命中的行，不锁间隙，新插入仍可发生 → 幻读回归 - ORM 中需绕过懒加载，直接写原生 SQL 或使用
select_for_update()（Django）或with_for_update()（SQLAlchemy），否则 ORM 可能拆成多条语句，锁失效
别盲目调高隔离级别到 SERIALIZABLE
SERIALIZABLE 会让所有 SELECT 隐式变成 SELECT ... LOCK IN SHARE MODE，看似一劳永逸，但代价巨大：
立即学习“Python免费学习笔记（深入）”；
- Web 请求并发量稍高就会触发大量锁等待，响应延迟陡增，错误日志里频繁出现
Lock wait timeout exceeded - Flask 或 FastAPI 的线程/协程池可能被阻塞耗尽，服务假死
- 与 Python 的 GIL 或异步事件循环交互时，锁持有时间不可控，容易引发死锁（尤其跨表 JOIN 场景）
真正可控的解法是收口事务边界 + 显式控制读类型
幻读本质是“读取结果集范围动态变化”，解决关键不在数据库配置，而在应用层让事务有明确生命周期和读意图：
- 用装饰器或中间件统一开启事务：Django 的
@transaction.atomic、FastAPI 的Depends(get_db)配合手动session.begin() - 区分快照读和当前读：对一致性要求高的操作（如生成报表前校验总数），强制用
SELECT ... FOR UPDATE；对容忍短暂不一致的列表页，保持普通SELECT - 检查连接池配置：SQLAlchemy 的
pool_pre_ping=True和max_overflow=0可减少因连接复用导致的隔离级别错乱
最容易被忽略的是：MySQL 的 transaction_isolation 变量是会话级的，Python 连接池里的空闲连接可能残留旧值。每次从池中取出连接后，应显式执行 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ，而不是只靠初始化设置。
