本文主要是介绍『MySQL 实战 45 讲』19 - 为什么我只查一行的语句，也执行这么慢？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
为什么我只查一行的语句，也执行这么慢？
- 需求：创建一个表，有两个字段 id 和 c，并且在里面插入了 10 万行记录
CREATE TABLE `t` (`id` int(11) NOT NULL,`c` int(11) DEFAULT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB;delimiter ;;
create procedure idata()
begindeclare i int;set i=1;while(i<=100000) doinsert into t values(i,i);set i=i+1;end while;
end;;
delimiter ;call idata();
查询长时间不返回
- 执行下面语句，长时间不返回
select * from t where id=1;
- 大概率是表 t 被锁住了，需要通过执行
show processlist命令，查看语句得状态
等 MDL 锁
- 使用
show processlist命令查看 Waiting for table metadata lock
- 出现这个状态表示的是，现在有一个线程正在表 t 上请求或者持有 MDL 写锁，把 select 语句堵住了
- 复现场景
- 解决办法就是找到持有 MDL 写锁的线程，然后 kill 掉
- 通过
show processlist只能看到 Command 是 “sleep” - 需要设置
performance_schema=on（相比于设置为 off 会有 10% 左右的性能损失，查询 sys.schema_table_lock_waits 表，找到 process id
# 查询是否开启
show variables like 'performance_schema'
# 找到有 MDL 写锁的线程
select blocking_pid from sys.schema_table_lock_waits;
等 flush
- MYSQL 里面对表做 flush 操作一般有以下两个
# 只关闭表 t
flush tables t with read lock;
# 关闭 MySQL 里所有打开的表
flush tables with read lock;
- Waiting for table flush 的复现步骤
- 通过
show processlist可以知道结果，从而排查问题
等行锁
- 行锁复现
show processlist现场
- 但是是查不到谁在占用这个写锁，可以通过下面命令来看
select * from sys.innodb_lock_waits where locked_table='`testdb`.`t`'\G
4. 可以看出 905 号线程是问题根源，可以执行 KILL QUERY 905 或者 KILL 905
KILL QUERY 905：表示停止 905 号线程当前正在执行的语句，而这个方法其实是没有用的。因为占有行锁的是 update 语句，这个语句已经是之前执行完成了的，现在执行 KILL QUERY，无法让这个事务去掉 id=1 上的行锁KILL 905：实际上，该命令才有效，也就是说直接断开这个连接。这里隐含的一个逻辑就是，连接被断开的时候，会自动回滚这个连接里面正在执行的线程，也就释放了 id=1 上的行锁
查询慢
- 扫描行数多，执行慢。通过查看慢查询日志，Rows_examined 可以看到扫描过的量
# 开启慢查询日志
SET GLOBAL slow_query_log=1;
# 查询是否开启慢查询日志
SHOW VARIABLES LIKE '%slow_query_log%';
# 设置慢查询时间
set long_query_time = 0;select * from t where c=50000 limit 1;
2. 扫描 1 行但是执行还是很慢的情况
- 复现步骤，其中会话 B 执行了 100w 次
- 这时候选择执行
select * from t where id=1会很慢，执行select * from t where id=1 lock in share mode会很快 - 因为生成了 100w 个回滚日志
这篇关于『MySQL 实战 45 讲』19 - 为什么我只查一行的语句，也执行这么慢？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
