SQL 事务隔离需按业务选合适级别：日志报表用 READ COMMITTED，银行转账用 REPEATABLE READ，跨行校验需 SELECT…FOR UPDATE 显式加锁；隔离级别不保证业务逻辑原子性，须配合正确事务边界与并发测试。
SQL 事务隔离的核心是通过设置合适的隔离级别，让并发操作既能保证数据一致性，又不牺牲过多性能。关键不是“越高越好”，而是根据业务场景选对级别，并配合正确的编程习惯。
隔离级别怎么选？看业务对一致性的实际要求
四种标准隔离级别（READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE）对应不同锁策略和可见性规则。多数业务无需 SERIALIZABLE —— 它用强锁或序列化执行，吞吐骤降，还可能引发大量死锁。
- 日志记录、统计报表类操作：READ COMMITTED 足够，避免脏读，开销小
- 银行转账、库存扣减等关键更新：REPEATABLE READ 更稳妥（MySQL 默认），防止同一事务内多次读取结果不一致
- 跨多行校验再更新的场景（如“余额≥100 才扣款”）：单靠隔离级别不够，必须加 SELECT … FOR UPDATE 显式加锁
别把隔离级别当万能锁——它不解决所有并发问题
隔离级别只控制“读可见性”和“写阻塞行为”，不自动保证业务逻辑原子性。常见误区是以为设了 REPEATABLE READ 就不会超卖，其实：
- 两个事务同时读到库存 =1 → 都判断“可扣减”→ 都执行 update → 库存变 -1
- 根本原因：读和写是分离操作，中间存在时间窗口
- 正确做法：用 SELECT stock FROM t WHERE id=1 FOR UPDATE（在读时加行锁），再判断 + 更新
事务边界要明确，别让长事务拖垮隔离效果
隔离机制生效的前提是事务及时开启和结束。以下写法会严重削弱隔离效果：
- 在事务中混入耗时操作（如调用外部 API、大文件处理）→ 锁持有时间过长，阻塞别人
- 用连接池但没显式 commit/rollback → 连接被复用时可能带着未提交事务，引发意外锁等待
- ORM 中误用 懒加载 ：事务已提交，后续 get() 触发新查询 → 不再受原事务隔离保护
测试不能只看单条 SQL——要模拟真实并发流
本地单线程跑通不等于线上安全。验证隔离效果必须做并发压测：
- 用脚本启动多个线程 / 进程，同时执行相同业务逻辑（如抢券、下单）
- 检查最终状态是否符合预期（如总库存不超发、金额平衡）
- 结合数据库日志（如 MySQL 的 innodb_status）观察锁等待、死锁信息
基本上就这些。隔离级别是 工具，不是银弹。理解它管什么、不管什么，再配上清晰的事务划分和必要时的显式锁，才能真正控住并发风险。
