中山森斯网站建设公司,做动画片的网站,公司宣传网站怎么做,购物网站页面布局一.查询被阻塞
A会话执行 查询操作#xff0c;长时间没有返回信息,此时我们就可以去排查一下是否是被阻塞了
select * from words 被阻塞的原因有很多#xff0c;首先列举第一种情况
1.等MDL锁
当我们执行DDL语句时#xff0c;会自动给表加上MDL写锁。当执行DML和DQL时长时间没有返回信息,此时我们就可以去排查一下是否是被阻塞了
select * from words 被阻塞的原因有很多首先列举第一种情况
1.等MDL锁
当我们执行DDL语句时会自动给表加上MDL写锁。当执行DML和DQL时会给表加上MDL读锁。
对MDL锁来说读读共享读写互斥。 因此有可能会话A正在执行DDL语句并且事务未提交。此时会话B执行DQL语句那么会话B将被阻塞查询语句长时间没有返回。
如果出现这种现象我们可以查询到等待MDL锁的现象
show processlist但是 id 86 是我们的查询语句想找出是哪个会话ID造成的查询语句堵塞还得使用下面的语句
select * from sys.schema_table_lock_waits此时可以看到是 87 阻塞了我们的查询语句把它kill掉即可
2.等待 Flush
flush tables words with read lock;flush tables with read lock;flush 表示 关闭所有已打开的表对象同时将查询缓存中的结果清空。就是说Flush tables的一个效果就是会等待所有正在运行的SQL请求结束。 因为SQL语句在执行前都会打开相应的表对象如select * from t1语句会找到t1表的frm文件并打开表内存对象。为了控制表对象使用的内存空间和其他资源MySQL会隐式后台表对象管理线程或显式flush tables等来关闭已打开但并没有使用的表对象。 然而正在使用的表对象是不能关闭的如SQL请求仍在运行因此Flush Tables操作会被正在运行的SQL请求阻塞。
3.等行锁
当执行下面的语句获取最新的值时将有可能被阻塞 (普通读不会加锁并不会阻塞)
select * from words w where id 1 lock in share mode ;如上图所示此时 session B 将被阻塞
如需找出死锁的会话ID可以通过下面的SQL进行排查
select * from sys.innodb_lock_waits;2.undo log导致查询慢 如上图所示由于MySQL 的MVCC多版本并发控制实现session b 将产生大量的 undo.log 日志
导致执行 select * from t where id 1一致性读需要遍历100W次并判断才能找到自己能读到的数据
而 select * from t where id 1 lock in share mode (当前读) 的速度将会很快因为当前读不需要遍历版本链
