Mysql并发DML锁等待的优化

1、概述​ 在Mysql数据库中慢SQL、长事务、没执行commit的DML操作都有可能导致并发会话的阻塞还可能发生锁等待报错。那么这一类的报错应该如何优化呢通常有三种方案可以考虑1优化SQL性能SQL执行快了阻塞时间自然就短了2使用合适的索引缩小数据上锁范围3调高锁等待超时时间参数。本文主要介绍第2种方案下面我们来看看实验效果2、实验场景1不使用索引在没有索引和主键的表上做update和delete操作锁定的是表中所有数据无论sql中是否含有过滤条件。先准备测试数据create table tb_test_lock1(id int ,c1 varchar(10)); insert into tb_test_lock1 values(1,aaa); insert into tb_test_lock1 values(2,bbb); insert into tb_test_lock1 values(3,ccc); insert into tb_test_lock1 values(4,ddd); insert into tb_test_lock1 values(5,eee); commit;在会话1中修改id1的数据不提交如下图。在这个会话中修改Id1的记录由于没有索引使用的是全部扫描的方式检索数据事务结束前会锁定整表数据而不是只锁定Id1的1条数据。#会话1 start transaction; update tb_test_lock1 set c1a1 where id1;与此同时在会话2中修改id5的数据可以看到因为会话1锁定了整表数据修改id5的sql被阻塞在超时后触发报错。#会话2 update tb_test_lock1 set c1e5 where id5;场景2创建索引缩小锁范围合适的索引能够缩小锁的范围减少并发锁冲突create index idx_id on tb_test_lock1(id);在会话1中修改id1的数据不提交如下图。#会话1 start transaction; update tb_test_lock1 set c1a1 where id1;与此同时在会话2中修改id5的数据如下图。我们看到会话2执行成功了这表明会话1并没有阻塞会话2。这是因为我们创建了索引idx_id会话1按索引idx_id检索数据数据上锁的范围变小了只锁定Id1的记录。而会话2请求的是Id5的记录锁2者不冲突。#会话2 update tb_test_lock1 set c1e5 where id5;实验表明创建合适的索引并使用索引字段做检索条件可以有效解决并发会话阻塞问题避免锁等待报错。​DLM 2026.7.21