SQL事务隔离需按业务选合适级别：READ UNCOMMITTED易脏读，READ COMMITTED为多数OLTP默认，REPEATABLE READ防不可重复读但可能幻读，SERIALIZABLE最高但性能差；事务应短小明确，避免嵌套与耗时操作；幻读与不可重复读不同，前者需范围查询新插入行；应用层配合（如显式加锁、乐观锁、拆分事务）比盲目提升隔离级别更有效。
SQL事务隔离的核心是通过隔离级别控制并发访问时的数据可见性，不是锁越多越安全，而是选对级别、配合适当的事务边界和业务逻辑。
隔离级别怎么选才不踩坑
四种标准隔离级别（READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE）对应不同一致性与性能的权衡：
- READ UNCOMMITTED：允许脏读，极少用于生产，调试或日志类非关键场景除外
- READ COMMITTED：默认级别（如 PostgreSQL、Oracle），每次 SELECT 都看到已提交的最新快照，适合多数 OLTP 场景
- REPEATABLE READ：MySQL 默认，同一事务内多次读取结果一致，但可能遇到幻读（新插入行被查到）；注意它在 MySQL 中通过间隙锁“模拟”可重复读，实际行为不完全等同于标准定义
- SERIALIZABLE：最高隔离，强制串行执行，开销大，仅在强一致性不可妥协时使用（如金融核心账务核对）
事务边界必须明确，不能靠“感觉”
常见误区是把长流程、用户交互或网络等待塞进事务里。事务应尽量短，只包裹真正需要原子性的一组数据库操作：
- 显式用 BEGIN / START TRANSACTION 开启，COMMIT 或 ROLLBACK 结束，避免依赖自动提交模式（autocommit=1）下隐式单语句事务
- 应用层调用数据库前确认连接是否已处于事务中，防止嵌套事务误判（多数数据库不真正支持嵌套事务）
- 不要在事务中做 HTTP 请求、文件读写、sleep 等耗时操作——会持锁阻塞他人，还可能因超时导致连接中断、事务悬挂
幻读和不可重复读的区别要分清
二者常被混淆，但触发条件和解决方式不同：
- 不可重复读：同一事务中两次 SELECT 同一行，值被其他事务 UPDATE/DELETE 并提交 → REPEATABLE READ 可防止
- 幻读：同一事务中两次 SELECT 相同行范围（如 WHERE status=1），第二次多出新插入的行 → 标准 SQL 中 SERIALIZABLE 才能防止；MySQL 的 REPEATABLE READ 借助间隙锁（Gap Lock）覆盖索引区间，也能抑制大部分幻读，但前提是查询走索引
- 没走索引的范围查询（如全表扫描），即使在 REPEATABLE READ 下仍可能幻读——这不是 bug，是隔离级别能力边界
应用层配合比死磕隔离级别更有效
过度依赖高隔离级别反而引发性能瓶颈甚至死锁。更务实的做法是：
- 用 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 显式加锁，锁定具体行而非依赖隔离级别“碰运气”
- 对金额、库存等关键字段，采用乐观锁（version 字段 + WHERE version = ?）减少锁冲突，尤其适合低冲突高并发场景
- 拆分长事务：例如“下单”可拆为“预占库存（事务）→ 支付回调（独立事务）→ 发货（独立事务）”，每步可补偿，而非包在一个大事务里
基本上就这些。隔离不是越严越好，关键是理解每个级别的行为边界，再结合业务数据特征、并发模型和失败容忍度做选择。写 SQL 时多看执行计划，查事务时多看锁状态，比背概念管用得多。
