扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
thread 1、begin;
创新互联建站专业为企业提供疏附网站建设、疏附做网站、疏附网站设计、疏附网站制作等企业网站建设、网页设计与制作、疏附企业网站模板建站服务,十载疏附做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
更新表;没有提交,也没有回滚操作
thread2、create index 在这个表上
这时候客户端超时中断
再次连接会话查询此表被阻塞,无法查询
thread3、查询 select * from test;
root@localhost : yaochong 17:08:27> select id,user,host,db,command,time,state,info from information_schema.processlist where user <>'system user' and info not like '%system user%'; +-------+------+-----------+----------+---------+------+---------------------------------+---------------------------------------------------------------+ | id | user | host | db | command | time | state | info | +-------+------+-----------+----------+---------+------+---------------------------------+---------------------------------------------------------------+ | 10161 | root | localhost | yaochong | Query | 3386 | Waiting for table metadata lock | select * from test | | 10092 | root | localhost | yaochong | Query | 6375 | Waiting for table metadata lock | alter table test add key(name) , ALGORITHM=INPLACE, LOCK=NONE | +-------+------+-----------+----------+---------+------+---------------------------------+---------------------------------------------------------------+ 2 rows in set (0.00 sec)
原因参考如下MDL的读写锁互斥
为什么C等待拿锁之后,D也会阻塞?其实这里并没有解释清楚。因为如果按并发理解的话,
C,D应当是同等级,都有可能拿到锁的。但C读写锁互斥,D读读不互斥,这样的话就跟上图所述相悖了。
就,查了一下。
(鸣谢 一梦如是YFL提供的文章)
首先是MDL(metaData Lock)的概念。元数据锁是server层的锁,表级锁,主要用于隔离DML(Data Manipulation Language,数据操纵语言,如select)和DDL(Data Definition Language,数据定义语言,如改表头新增一列)操作之间的干扰。 每执行一条DML、DDL语句时都会申请MDL锁, DML操作需要MDL读锁,DDL操作需要MDL写锁(MDL加锁过程是系统自动控制,无法直接干预,读读共享,读写互斥,写写互斥)
申请MDL锁的操作会形成一个队列,
队列中写锁获取优先级高于读锁
。一旦出现写锁等待,不但当前操作会被阻塞,同时还会阻塞后续该表的所有操作。事务一旦申请到MDL锁后,直到事务执行完才会将锁释放。(这里有种特殊情况如果事务中包含DDL操作,MySQL会在DDL操作语句执行前,隐式提交commit,以保证该DDL语句操作作为一个单独的事务存在,同时也保证元数据排他锁的释放,例如id 44的语句改为
这样就能解释通为什么session C被阻塞后,session D也运行不了的原因了。
简而言之MDL锁互斥,select也要申请MDL的读锁,这一点真是有点恶心。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流