多数应用应选read committed，仅在需强一致性时升至repeatable read或serializable；需结合业务场景、数据库特性及orm配置综合权衡，避免盲目设高隔离级别引发性能与死锁问题。
SQL 事务隔离级别怎么选才不踩坑
多数应用默认用 READ COMMITTED，但这不是万能解——它防不住不可重复读，也拦不住幻读；盲目升到 SERIALIZABLE 又容易触发锁等待甚至死锁。关键不是“选最高”，而是看业务是否真需要强一致性。
-
READ UNCOMMITTED：仅适合日志类、监控类查询，容忍脏读；MySQL 实际不支持该级别（会自动降级为READ COMMITTED） -
REPEATABLE READ（MySQL 默认）：靠 MVCC 避免不可重复读，但幻读仍可能（比如SELECT ... FOR UPDATE范围扫描时新插入的行） -
SERIALIZABLE：所有SELECT自动加读锁，写操作锁范围扩大，QPS 明显下降；PostgreSQL 中实际是通过可串行化快照实现，开销比 MySQL 小，但仍有延迟风险
幻读到底在什么场景真实发生
幻读不是理论问题，它常出现在「先查后插」或「范围条件更新」逻辑里。比如电商库存扣减前检查剩余量：SELECT stock FROM items WHERE id = 123 返回 5，接着执行 UPDATE items SET stock = stock - 1 WHERE id = 123 AND stock >= 1 ——看似安全，但如果并发事务在此期间插入了另一条 id = 123 的记录（极端但可能，尤其分库分表 ID 生成不唯一时），就可能绕过校验。
- 更典型的幻读场景：分页查询 + 后台新增数据，用户刷新第二页看到重复或跳过记录
- MySQL 在
REPEATABLE READ下对当前读（如SELECT ... FOR UPDATE）使用间隙锁（gap lock），能锁住不存在的区间，从而抑制部分幻读；但普通SELECT不加锁，不生效 - PostgreSQL 没有间隙锁，靠可串行化快照检测冲突，失败时抛出
SerializationFailure错误，需应用层重试
ORM 框架里的隔离级别设置陷阱
很多开发者以为在 Spring 的 @Transactional(isolation = Isolation.SERIALIZABLE) 或 SQLAlchemy 的 session.begin(isolation_level="SERIALIZABLE") 里设了就行，其实底层是否真正生效，取决于数据库驱动和连接配置是否透传。
- MySQL Connector/J 默认忽略 JDBC 的 isolation 设置，需显式启用：连接 URL 加
&useServerPrepStmts=true，否则仍走客户端模拟 - Django 的
transaction.atomic(using='default', savepoint=False)不控制隔离级别，得靠connection.cursor().execute("SET TRANSACTION ISOLATION LEVEL ...")手动发指令 - Go 的
sql.Tx构造时传入sql.IsolationLevel，但 SQLite 不支持除Serializable外的其他级别，PostgreSQL 则要求在BEGIN后立即执行SET TRANSACTION ISOLATION LEVEL，晚了会报错
如何验证当前查询实际运行在哪种隔离下
别信文档，也别信 ORM 日志——它们只显示“意图”，不反映数据库真实行为。最可靠的方式是直接查会话状态或锁信息。
- MySQL：执行
SELECT @@tx_isolation看会话级设置；配合SELECT * FROM performance_schema.data_locks观察当前持有的锁类型和范围 - PostgreSQL：查
SELECT backend_xid, backend_xmin, state FROM pg_stat_activity WHERE pid = pg_backend_pid()，再结合pg_locks判断是否进入可串行化模式 - 注意：某些云数据库（如 AWS RDS MySQL）会禁用
performance_schema，此时只能靠慢日志 +SHOW ENGINE INNODB STATUS推断锁行为
隔离策略不是开关，是权衡链：从语句粒度、事务长度、并发模型到错误处理方式，每一环松动都会让隔离失效。最容易被忽略的是——你以为加了锁，其实锁的是空范围；你以为用了 MVCC，其实快照早被垃圾回收了。
