SQL 数据访问隔离策略实践

多数应用应选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，其实快照早被垃圾回收了。