01.26 Day 7 - 表锁、行锁和一致性读

本文主要是介绍01.26 Day 7 - 表锁、行锁和一致性读，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

大家好，我是 Snow Hide，作为《MySQL 实战》这个专栏的学员之一，这是我打卡的第 7 天，也是我第 49 次进行这种操作。

今天我温习了该专栏里一篇叫《为什么我只查一行的语句，也执行这么慢？》的文章。

关键词总结：第一类语句慢的原因，查询长时间不返回（等 MDL 锁、等 flush、等行锁）、第二类语句慢的原因，查询慢（一致性读、当前读）。

 

所学总结：

 

第一类语句慢的原因，查询长时间不返回

使用 show processlist 命令查看当前语句的状态。

等 MDL 锁

Waiting for table metadata lock 的意思是，现在有一个线程正在表上请求或者持有 MDL 写锁，把 select 语句堵住了。
以性能损耗 10% 为代价将 performance_schema 设置成 on 之后，通过查询 sys.schema_table_lock_waits 这张表，就可以直接找出造成阻塞的 process id，把这个连接用 kill 命令断开即可。

等 flush

Waiting for table flush 的意思是，现在又一个线程正要对表做 flush 操作。MySQL 里面对表做 flush 操作的用法，一般有以下两个：

flush tables 表名 with read lock;
flush tables with read lock;

等行锁

由于访问某个记录时要加锁，如果这时已经有一个事务在这行记录上持有一个写锁，我们的查询语句就会被堵住。
加锁读时：

select * from 表名 where id=1 lock in share mode;

MySQL 5.7 可以通过 sys.innodb_lock_waits 表查到占用写锁的连接：

select * from t sys.innodb_lock_waits where locked_table='`test`.`t`'\G

可以通过 sql_kill_blocking_connection 的值来杀掉连接。
 

第二类语句慢的原因，查询慢

执行 set long_query_time=0 来将慢查询的阈值设置为 0。然后查看慢查询日志。

select * from t where c=50000 limit 1;

由于字段 c 上没有索引，这个局与只能走 id 逐渐顺序扫描，因此需要扫描 5 万行。

一致性读

看一个只扫描一行，但是执行很慢的语句：

select * from t where id=1；

扫描行数是 1，但执行时间却长达 800 毫秒。
由于 select * from t where id=1 是一致性读，因此需要从末尾开始，依次执行 undo log，执行了 N 次以后，才将 1 这个结果返回。

当前读

select * from t where id=1 lock in share mode；

而加了 lock in share mode 的 SQL 语句是当前读，所以只要 0.2 毫秒。
 

末了

重新总结了一下文中提到的内容：查一行可能出现被锁和执行慢的情况、表锁、行锁、一致性读。

这篇关于01.26 Day 7 - 表锁、行锁和一致性读的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---