32 kill不掉的语句

在mysql中有两个kill命令：一个是kill query+线程id，表示终止这个线程正在执行的语句；一个是kill connection+线程id，缺省connection值，表示断开这个线程的连接，当然如果这个线程有语句正在执行，也是要先停止正在执行的语句。

在大多数情况下，kill query/connection的命令是有效的。比如，执行一个查询的过程中，发现执行时间太久，要放弃查询，就可以用kill 命令，来终止这个查询。

还有一种情况，语句处于锁等待的时候，直接使用kill命令也是有效的

SESSION A	SESSION B	SESSION C
begin; update t32 set c=c+1 where id=1;
	update t32 set c=c+1 where id=1;(blocked)
	Error 1317 :query execution was interrupted	Kill query thread_id_B;

收到kill以后，线程做了什么

Session b是直接终止掉线程，什么都不管就直接退出吗？这是不行的。

当对一个表做dml操作的时候，会在表上进行mdl读锁，所以，session b虽然处于blocked状态，但是还持有一个mdl读锁，如果线程被kill的时候，就直接终止，那之后这个mdl读锁就没有机会释放了。

所以，kill并不是马上就停止的意思，而是告诉执行线程，这条语句已经不需要继续执行了，可以开始”执行停止的逻辑了”

--其实，这根linux的kill命令类似，kill -N pid并不是让进程直接停止，而是给进程发一个信号，然后进程处理这个信号，进入终止逻辑，只是对mysql的kill命令来说，不需要传信号参数，只有停止这个命令。

当用户在执行kill query sessionB，mysql处理kill命令做了两件事：

--1 把session B的运行状态改成thd:kill_query(将变量killed赋值给the:kill_query)

--2 给session B的执行线程发一个信号

当kill执行的时候，kill不掉的时候

在show processlist中command的状态时Killed，在等待锁时，使用的函数这个等待状态可以被唤醒，但是，在执行的个别逻辑里面，如果不行，就进行sleep状态，可以在开一个session，执行kill线程的命令。

线程没有执行到判断线程状态的逻辑，由于io压力过大，读写io的函数一直返回，导致不能及时判断线程的状态。

另一种情况是，终止逻辑耗时较长，常见的情况：

--1 超大事务执行期间被kill，回滚操作需要对事务期间生成的所有新数据版本做回收操作，耗时很长。

--2 大查询回滚，如果查询过程中生成了比较大的临时文件，加上此时文件系统压力大，删除临时文件可能需要等待io资源，到时耗时较长。

--3 ddl命令执行到最后阶段，如果被kill，需要删除中间过程中的临时文件，也可能受io资源影响耗时较久。

如果直接在客户端执行crtl+c 是不能直接终止线程的。

在执行ctrl+c的时候，是mysql客户端另外启动一个连接，然后发送一个kill query命令。

误解：如果库里面的表特别多，连接就会很慢

在一个库里面，如果表过多（6w多张表），会发现，每次用客户端连接就会卡在连接的界面，比较耗时

而如果db这个库里面的表比较少的话，连接起来就会很快

在客户端连接，每个客户端在和服务器建立连接的时候，需要做的事情就是tcp握手，用户校验，获取权限，这几个操作，显然跟数据库里面的表的数量无关。

但是，当使用默认连接的时候，mysql客户端会提供一个本地库名和表名的补全功能，为了实现此功能，客户端在连接成功，需要多做一些操作：

--执行show databases

--切到db1，执行show tables

--把这两个命令的结果用于构建一个本地的哈希表

可以根据提示，在连接命令中加参数-A，可以关掉这个自动补全的功能，客户端就可以很快的返回。

Mysql客户端发送请求后，接收服务端返回结果的方式有两种

--1 一种是本地缓存，在本地开一片内存，先把结果存起来，如果用api开发，对应就是mysql_store_result方法

--2 另一种是不缓存，读一个处理一个，对应api开发mysql_use_result方法

Mysql客户端默认采用第一种方式，如果加上-quick参数，就会使用第二种。

使用quick参数的效果

--跳过表名自动补全

--mysql_store_result需要申请本地内存来缓存查询结果，如果查询太大，会耗费较多的本地内存

--不会把执行命令记录到本地的历史命令文件