事务优化关键在于精准控制边界、隔离级别与资源协同：缩小范围、异步非DB操作、分段提交+补偿、批量SQL、按需选隔离级、用行锁防超卖、读写分离、下推逻辑至SQL、监控预警。
事务处理在复杂业务场景中容易成为性能瓶颈和数据一致性风险点，关键不在“加事务”，而在于精准控制事务边界、合理隔离级别与协同资源管理。
缩小事务作用范围，只包必要操作
长事务会锁表、阻塞并发、拖慢响应，尤其在涉及多表更新、远程调用或文件写入的场景中。应把非数据库操作（如发消息、写日志、调第三方接口）移出事务体；对可拆分的业务流，用“分段提交+补偿机制”替代单一大事务。
- 例如订单创建：库存扣减 + 订单写入必须在事务内；但通知物流、更新搜索索引、发短信应异步处理
- 使用 savepoint 实现局部回滚，避免整个事务因某一步失败而全盘撤回
- 批量操作慎用单条 INSERT/UPDATE 包裹循环，改用批量语句（如 INSERT ... VALUES (...), (...), (...)）并控制批次大小（500~1000 行较稳妥）
按业务语义选对隔离级别，不盲目用 SERIALIZABLE
默认 READ COMMITTED 多数场景已够用；高并发查+少量写冲突时，可评估 READ UNCOMMITTED（仅限日志、监控等允许脏读的场景）；真正需要防幻读且无法接受应用层校验的，才考虑 REPEATABLE READ 或带 SELECT FOR UPDATE 的显式加锁。
- 电商秒杀需防超卖：用 UPDATE stock SET count = count - 1 WHERE id = ? AND count >= 1，配合行锁 + 影响行数判断，比锁全表或升隔离级别更轻量
- 报表类查询尽量走只读副本，避免与 OLTP 事务争抢主库资源
- 避免在事务中执行耗时查询（如 JOIN 十几张表），先取关键ID，再分步加载
善用数据库原生能力减少应用层协调
把校验、计算、状态流转逻辑尽可能下推到 SQL 层，降低网络往返与应用状态维护成本。同时利用 RETURNING、CTE、UPSERT 等特性提升原子性与简洁度。
- 插入时自动获取生成主键：INSERT INTO orders (...) VALUES (...) RETURNING id
- 避免“先查再插”导致的竞态：用 INSERT ... ON CONFLICT DO NOTHING / UPDATE（PostgreSQL）或 MERGE（SQL Server）
- 状态机更新带条件校验：UPDATE tasks SET status = 'done' WHERE id = 123 AND status = 'processing'，成功才继续后续动作
监控与预案比盲目优化更重要
上线前必须有事务执行时长、锁等待、死锁频次等核心指标采集；对关键事务标注业务上下文（如通过 application_name 或注释 /* order_create_v2 */），便于问题定位。
- 设置事务超时（如 JDBC 的 queryTimeout、Spring 的 @Transactional(timeout = 30)），防止挂起阻塞连接池
- 定期分析 pg_stat_activity（PostgreSQL）或 information_schema.INNODB_TRX（MySQL），识别长事务源头
- 对高频小事务（如积分变更），考虑合并为批量操作或引入内存队列缓冲，再定时刷库
事务不是万能锁，而是业务一致性的契约。设计时从“这笔钱不能少、这个单不能重、这个状态不能跳”出发，倒推最小必要约束，比套模板更有实效。
