事务隔离级别需按业务权衡一致性与性能：只读场景用read committed，强一致场景才用repeatable read；配合索引优化、缩小事务粒度、规避间隙锁，并通过performance_schema和innodb状态监控锁行为。
事务隔离级别直接影响数据库并发性能和数据一致性，选错级别会导致锁争用、死锁或不可重复读等问题。优化核心是：在满足业务一致性的前提下，尽可能使用更低的隔离级别，并配合索引、语句写法和事务粒度控制来减少锁范围与时长。
按业务需求降级隔离级别
多数应用无需默认的 REPEATABLE READ 或更高级别。例如：
- 报表类查询、统计汇总等只读场景，可安全使用 READ COMMITTED，避免间隙锁，显著降低锁冲突；
- 用户资料查看、商品详情页等对“幻读”不敏感的操作，甚至可在会话级临时设为 READ UNCOMMITTED（需确认脏读可接受）；
- 银行转账、库存扣减等强一致性场景才需 REPEATABLE READ 或 SERIALIZABLE，但应尽量缩短事务内操作步骤。
减少锁持有时间与范围
隔离级别影响锁行为，但锁的实际持续时间和覆盖行数更取决于 SQL 写法和索引：
- 确保 WHERE 条件字段有高效索引，避免全表扫描导致锁住大量无关行；
- UPDATE/DELETE 尽量带精确主键或唯一索引条件，不要用模糊匹配（如 LIKE '%xxx'）；
- 把耗时操作（如远程调用、文件读写、复杂计算）移出事务块，只保留 DB 操作；
- 批量更新拆分为小批量（如每次 100 行），配合 COMMIT 分段释放锁。
识别并规避间隙锁陷阱
REPEATABLE READ（MySQL 默认）在范围查询时会加间隙锁，极易引发死锁或阻塞。应对方式：
- 用 SELECT ... FOR UPDATE 时，明确指定主键或唯一索引，避免走二级索引+间隙锁组合；
- 插入前先 SELECT 检查是否存在？改用 INSERT ... ON DUPLICATE KEY UPDATE 或 INSERT IGNORE，原子处理且不依赖间隙锁；
- 高并发插入场景，考虑用 REPLACE INTO 或 UUID 主键替代自增 ID，缓解索引热点和间隙锁竞争。
监控与验证实际锁行为
别只看隔离级别设置，要观察真实锁表现：
- MySQL 中执行 SELECT * FROM performance_schema.data_locks; 查看当前锁类型与范围；
- 用 SHOW ENGINE INNODB STATUS\G 分析最近死锁日志，定位是否由隔离级别+SQL 组合引发；
- 压测时对比不同隔离级别下的 TPS、平均响应时间、锁等待次数（如 Innodb_row_lock_time_avg）。
