kill query + 线程id :终止这个线程正在执行的语句
kill connection + 线程id :关闭这个线程的连接,也会先停止这个线程正在执行的语句。这个connection可以缺省。
本文讨论的情况是:使用了kill命令,却没有断开连接,show processlist命令执行结果中,被kill的线程显示killed,这个killed是什么意思?以及一些常见的命令误解
1.收到kill query命令后,线程会做什么?
1.MYSQL中有个处理的kill命令的线程,处理kill命令的线程首先会设置该线程的状态为KILL_QUERY
2.给该线程发送一个“你被kill了”的信号
一个语句的执行过程中有多处埋点,执行到埋点处就会判断自己的线程状态。
如果线程在等待某个资源,那这个等待必须是可以唤醒的,否则就无法到达埋点处。
执行kill query 线程id命令,处理kill命令的线程首先会设置该线程的状态为KILL_QUERY,然后给该线程发送一个信号,该线程收到信号后知道自己被kill了,如果正在锁等待,就停止等待。去处理这个KILL_QUERY状态。 如果不发信号,该线程就仍然在锁等待,不知道自己被kill了。
2.收到kill connection命令后,会发生什么?
1.将被kill线程的状态设置为Kill_Connection
2.关闭被kill线程的网络连接
3.由于最大并发线程数不够导致的新线程等待并且kill不掉
当线程数已经达到最大并发线程数(innodb_thread_concurrency),此时一个新的查询请求想进来,需要等待有空闲线程,所以会每隔10ms尝试进入一次,并没有去判断线程的状态,所以此时kill query这个线程是没用的,而kill connection是可以的,直接关闭网络连接,但是一查,该线程仍然在等待中,不过状态是KILLED,因为
如果一个线程的状态是KILL_CONNECTION,就会把Command列显示成Killed。
为什么这样设计,因为断开连接只是将客户端和服务端连接断开了,而服务端的线程还是存在的。
那么该线程什么时候才能停止呢?
答案是要等到该线程能够进入innodb时,才会判断出自己的状态是了KILL_QUERY或者KILL_CONNECTION,此时才会进入终止线程的逻辑。
4.由于耗时长导致的一段时间内线程kill不掉
情况1:大事务,被kill时要将前面的更改都回滚,耗时长。
情况2:大查询回滚。
情况3:DDL命令执行到最后时被kill。
关于客户端的3个误解
1.在一个查询语句长时间阻塞时,客户端直接执行ctrl+c可以终止这个线程吗?
是不可以的,执行ctrl+c时,是启动另一个线程向服务端发送kill query命令,而MYSQL是停等协议,也就是要等到客户端的操作只能影响你客户端的线程,你ctrl+c只是客户端线程终止,只是你客户端退出了,服务端的线程仍然在运行。
2.数据库的表特别多,客户端连接就会很慢
客户端连接服务端需要执行的步骤是TCP握手,用户账号密码校验,获取权限。
可以看出来与表的数量没有关系。
表越多连接越速度越慢的原因是
客户端在连接成功后,需要将“每个库有哪些表”存本地缓存,用于名称补全的。
使用-A可以取消掉这个操作。
3.-quick命令不会让服务端变快
MYSQL客户端发送请求后,接收服务端返回结果的方式有两种:
1.在本地开个缓存,先把结果存起来。
2.不缓存,读一个处理一个
默认是第一个,而使用-quick就算第2个设置。
如果不缓存,本地如果处理慢了,就会导致服务端的结果被阻塞(因为停等协议),就导致服务端变慢了。