并发一上来，数据库就开始报锁等待超时（Lock wait timeout exceeded），业务接口大面积变慢甚至挂起，这种情况在电商秒杀、批量任务调度、消息消费等高并发场景里非常常见。造成表锁定的原因有很多种，其中相当一部分和事务隔离级别直接相关。MySQL的InnoDB引擎默认使用RR（可重复读）隔离级别，它为了保证事务内读取的一致性，引入了间隙锁和临键锁机制，而这些锁在并发更新、范围查询更新的场景下，极易引发锁冲突甚至死锁。将隔离级别调整为RC（Read Committed，读已提交）是缓解这类问题的常用手段之一，但调整之前必须搞清楚原理，否则可能按下葫芦浮起瓢。
一、先定位：确认锁到底锁在哪里
遇到锁问题，第一步不是急着改配置，而是先弄清楚是哪个事务持有了锁、哪个事务在等待。MySQL提供了几个非常好用的观测手段。
第一个是performance_schema中的data_locks和data_lock_waits表（MySQL 8.0以上），或者是老版本的information_schema.INNODB_LOCKS和INNODB_LOCK_WAITS。通过它们可以直接看到锁的类型、锁定的索引、持有锁的事务ID。
-- 查看当前存在的锁（MySQL 8.0）
SELECT * FROM performance_schema.data_locks;
-- 查看锁等待关系，找出谁在阻塞谁
SELECT
r.trx_id AS waiting_trx,
r.trx_query AS waiting_query,
b.trx_id AS blocking_trx,
b.trx_query AS blocking_query
FROM performance_schema.data_lock_waits w
JOIN information_schema.innodb_trx r ON r.trx_id = w.REQUESTING_ENGINE_TRANSACTION_ID
JOIN information_schema.innodb_trx b ON b.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID;</code>第二个是SHOW ENGINE INNODB STATUS，输出中的LATEST DETECTED DEADLOCK段落会详细记录最近一次死锁的双方事务、各自执行的SQL以及持有和等待的锁。排查时重点看被锁定的索引记录（lock_mode字段），如果看到lock_mode X locks gap这样的字样，基本可以确认是间隙锁引起的冲突，这就和RR隔离级别直接挂钩了。
第三个是information_schema.innodb_trx，它列出当前所有活跃事务。如果发现有事务长时间处于RUNNING状态且trx_rows_locked数值很大，通常说明这个事务忘了及时提交，持有大量行锁不放，成为阻塞源头。很多时候所谓的表锁死，本质就是某个慢事务持有锁不释放，其他连接全部排队等待而已。
二、RR与RC在加锁行为上的核心差异
要理解为什么调到RC能缓解锁冲突，需要先弄清楚两个隔离级别的加锁逻辑区别。
在RR隔离级别下，InnoDB为了防止幻读，对范围查询加的是临键锁（Next-Key Lock），它等于记录锁加上间隙锁。举例来说，执行UPDATE orders SET status=1 WHERE id > 100 AND id < 200时，RR不仅会锁住这个区间内已有的记录，还会锁住区间内的间隙，阻止其他事务在这个范围内插入新行。如果两个事务的更新范围有交叠，或者一个事务更新、另一个事务插入到被锁的间隙里，锁等待就发生了，严重时直接死锁。
而在RC隔离级别下，间隙锁被禁用了，只保留记录锁（对索引记录本身加锁），并且支持半一致读特性：对于不匹配WHERE条件的行，InnoDB会在扫描后提前释放锁，而不是像RR那样一直持有到事务结束。这意味着锁的粒度更小、持有时间更短，并发冲突概率显著降低。在生产环境的实测中，高并发写入场景从RR切换到RC后，锁等待事件减少的情况非常普遍。
当然RC也有代价。首先是不可重复读问题：同一个事务内两次相同的查询可能返回不同结果。其次是主从复制方式必须调整，RC下无法继续使用基于语句的复制（statement格式），因为语句执行结果受其他事务提交影响，重放会不一致，必须改用ROW格式的binlog。好在MySQL 5.7.7之后默认就是ROW格式，这条限制对大多数现代系统影响不大。
三、如何安全地将隔离级别调整为RC
调整隔离级别有会话级和全局级两种方式，建议分阶段操作，不要一步到位改全局。
会话级调整只影响当前连接，适合先在灰度服务上验证效果：
-- 仅当前会话生效 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 验证当前隔离级别 SELECT @@transaction_isolation; -- 结果应为 READ-COMMITTED
确认没有问题后，再做全局调整。全局修改会影响新建立的连接，已有连接不受影响，所以最好配合应用侧的重连或发布来让配置全面生效：
-- 全局生效（重启后失效） SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 持久化到配置文件 my.cnf 的 [mysqld] 段 -- transaction-isolation = READ-COMMITTED
如果使用的是阿里云RDS、腾讯云等托管数据库，也可以直接在控制台的参数设置里修改transaction_isolation参数，效果等同于修改配置文件。
调整之后还有几件事必须验证：第一，确认binlog格式是ROW，执行SHOW VARIABLES LIKE 'binlog_format'查看，如果不是需要一并调整，否则主从复制会直接报错；第二，检查业务代码中是否存在依赖可重复读语义的逻辑，比如同一个事务里先查余额再查余额做比对，在RC下两次结果可能不同，这类逻辑要改成一次性读取或在应用层加一致性校验；第三，观察Show engine innodb status中的锁等待指标，确认优化确实生效。
四、调整隔离级别之外的补充手段
隔离级别调整能显著减少间隙锁冲突，但它不是万能药，配合以下手段效果更好。
第一是给SQL涉及的字段建立合适的索引。没有索引的更新语句在RC下依然可能扫描大量行并逐行加锁，锁冲突照样严重。确保WHERE条件命中索引，让锁精确落在目标行上，这是所有锁优化的前提。
第二是缩短事务的持有时间。把耗时的RPC调用、文件操作、消息发送等移到事务外，事务里只保留纯数据库操作，锁持有时间从秒级降到毫秒级，冲突概率自然下降。同时要避免大事务，比如一次性更新几十万行的操作，应拆分成小批次，每批次独立提交。
第三是统一加锁顺序并做好重试。多个事务需要更新多张表或多行记录时，保证按相同顺序访问，可以从结构上杜绝死锁。对确有可能发生死锁的写操作，应用层捕获1213死锁错误码后做短暂等待重试，通常一两次重试就能成功。
第四是合理设置锁等待超时参数。innodb_lock_wait_timeout默认50秒，对高并发业务来说太长了，可以把调整到几秒，让被阻塞的连接快速失败并走重试逻辑，避免连接堆积拖垮整个数据库。此外关注innodb_deadlock_detect保持开启，让InnoDB自动检测并回滚死锁一方。
总的来说，从RR切换到RC是缓解并发锁竞争立竿见影的一招，尤其适合写并发高、又不需要严格可重复读语义的互联网业务。但它只能解决间隙锁这一类问题，索引缺失、长事务、大事务这些根源性问题仍需逐项排查治理。调整前做好复制格式检查和业务语义评估，调整后持续观察锁指标，才能真正做到安全落地。
SQL表锁定事务隔离级别Read Committed修改时间：2026-09-13 04:54:36