MySQL的事务锁机制是保证数据一致性的重要基础，但在高并发场景下，锁等待过长会直接导致业务接口延迟升高。减少事务锁定的资源数量是优化锁等待性能的核心方向之一，下面从原理到实践展开说明。
MySQL事务锁的基本机制
MySQL的InnoDB引擎默认采用行级锁，事务执行过程中会对操作涉及的行加锁，直到事务提交或回滚才会释放。如果多个事务同时操作同一批资源，就可能出现锁等待：后请求锁的事务需要等待先持有锁的事务释放锁后才能继续执行。
常见的锁类型包括行锁、间隙锁、临键锁，其中间隙锁和临键锁是RR隔离级别下的特有锁，会锁定索引记录之间的间隙，进一步增加锁定资源的范围。
锁等待产生的核心原因
除了业务本身的高并发竞争，锁等待时间过长大多和锁定资源数量过多有关，常见原因包括：
- 事务中包含大量无关的数据操作，锁定了不需要修改的资源
- 查询没有命中索引，导致行锁升级为表锁，锁定全表资源
- 事务隔离级别设置过高，引入了不必要的间隙锁
- 大事务执行时间过长，锁持有时间被拉长
减少锁定资源数量的具体优化方案
1. 优化事务中的查询条件，确保命中索引
如果事务中的更新、删除语句没有命中索引，InnoDB无法定位到具体的行，就会对全表加锁，极大增加锁定资源数量。因此需要检查事务内所有写操作的WHERE条件，确保对应字段有合适的索引。
例如下面的更新语句，如果user_id没有索引，会锁定整张user表：
-- 无索引时的危险操作 UPDATE user SET status = 1 WHERE user_name = 'test'; -- 给user_name添加索引后，只会锁定匹配的行 ALTER TABLE user ADD INDEX idx_user_name (user_name);
2. 降低事务隔离级别
如果业务对幻读不敏感，可以将事务隔离级别从默认的RR（可重复读）调整为RC（读已提交）。RC级别下不会使用间隙锁，只会锁定实际存在的行，能大幅减少锁定的资源范围。
查看和调整隔离级别的语句如下：
-- 查看当前隔离级别 SELECT @@transaction_isolation; -- 设置会话级隔离级别为RC SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
3. 拆分大事务，减少单次事务锁定的资源量
很多开发者习惯把多个业务逻辑放在同一个事务中，比如批量更新1000条用户数据放在一个事务里，会导致这1000行资源长时间被锁定。可以将大事务拆分成多个小事务，每次只处理少量数据，缩短单事务的锁持有时间，同时减少单次锁定的资源数量。
例如批量更新用户状态的优化示例：
// 优化前：一个大事务处理所有数据
@Transactional
public void batchUpdateUserStatus(List<Long> userIds) {
for (Long userId : userIds) {
userMapper.updateStatus(userId, 1);
}
}
// 优化后：拆分小事务，每次处理100条
public void batchUpdateUserStatusSplit(List<Long> userIds) {
int batchSize = 100;
for (int i = 0; i < userIds.size(); i += batchSize) {
List<Long> subList = userIds.subList(i, Math.min(i + batchSize, userIds.size()));
updateBatchSub(subList);
}
}
@Transactional
public void updateBatchSub(List<Long> userIds) {
for (Long userId : userIds) {
userMapper.updateStatus(userId, 1);
}
}
4. 事务中避免无关查询，缩小操作范围
不要在事务中执行和本次数据修改无关的查询操作，比如先查询所有用户信息再过滤出需要修改的部分，这样会锁定查询涉及的所有行。应该直接通过精准的WHERE条件定位需要修改的行，减少不必要的资源锁定。
5. 控制事务执行顺序，避免死锁和长等待
如果多个事务都需要锁定多行资源，约定统一的资源访问顺序，比如都按照主键从小到大的顺序操作，能减少锁竞争的概率，避免部分事务长时间等待锁。
优化效果验证
可以通过MySQL的performance_schema库查看锁等待的相关指标，验证优化效果：
-- 查看当前锁等待情况 SELECT * FROM performance_schema.data_lock_waits; -- 查看锁等待的历史统计 SELECT * FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE 'wait/lock/transaction%';
如果优化后锁等待的次数和平均等待时间明显下降，说明减少锁定资源的优化起到了作用。
注意事项
减少锁定资源数量的同时，也要保证事务的ACID特性，不能为了优化锁性能而牺牲数据一致性。如果业务必须保证可重复读或者避免幻读，就不要盲目降低隔离级别，可以从索引优化、拆分事务等其他方向入手。