本文探讨了MySQL中查询长时间不返回和查询慢的常见原因，包括等待MDL锁、flush操作堵塞以及行锁冲突。通过showprocesslist和sys.schema_table_lock_waits监控锁状态，使用kill命令解除阻塞。同时，分析了在可重复读隔离级别下，一致性读与当前读的区别，以及undo log对查询性能的影响。了解这些机制有助于优化数据库性能。
先补充几条指令
①可以用 show processlist查看连接状态
show processlist
②可以用lock table 表名 WRITE/READ 来模拟指定加读锁还是写锁，用unlock tables来是释放锁
③查看占有锁的pid
SELECT blocking_pid FROM sys.schema_table_lock_waits
只查询一行语句,但是却很慢的原因(CPU占用率高,IO占用率高都不在这次的讨论范围内)
一.查询查询长时间不返回
1.等待MDL锁(元数据锁)
元数据锁是server层的锁，表级锁，主要用于隔离DML和DDL操作之间的干扰
DML操作只会申请MDL读锁，如果有其他线程获取了MDL写锁，则该线程在执行DDL操作
比如sessionA持有了表user的MDL写锁,此时sessionB对表user进行的操作会阻塞直到sessionA释放锁,可以用SELECT blocking_pid FROM sys.schema_table_lock_waits来查看阻塞的id,用kill命令断开连接即可释放锁
2.flush
Waiting for table flush状态的可能情况：flush命令被别的指令堵住了,然后这个flush命令来堵我们当前的命令
flush tables t with read lock; //锁指定表 flush tables with read lock; //锁所有表
flush操作正常情况下执行很快,除非他们被别的线程堵住了
解决方法：将堵住flush操作的线程结束,方法同1
3.等行锁
sessionA开启事务然后占用写锁且未提交,此时sessionB就会被困住
mysql5.7可以用来着看是哪张表占用了写锁
select * from t sys.innodb_lock_waits where locked_table='`test`.`t`'\G
还是一样用kill pic 来释放行锁
二.查询慢
其中一个原因是undolog过大导致一致性读回滚日志消耗太多时间
先看下面这个例子,第二条语句加了意向共享锁,但是却执行的更快,并且可以发现有加锁和没加锁读到的数据不一样(因为在这次两句sql所在的事务还未提交,但是别的事务已经把c加1加了100万次)
导致数据不一样的原因是：在可重复读的隔离级别下,在事务中带lock in share mode是当前读,不带的是一致性读,当前都可以直接读取到100001这个最新的数据,但是普通的select是一致性读,因此需要从 1000001 开始，依次执行 undo log，执行了 100 万次以后，才将 1 这个结果返回。
(回归日志过大导致一次读慢,当前读快)
在可重复读隔离级别下，consistent snapshot才有意义
扫一扫
1492