网站建设 seo优化,开发商建设审批网站,北京最新消息今天新闻,重庆建网站搜索快忻科技MySql的kill命令
Hi#xff0c;我是阿昌#xff0c;今天学习记录的是关于MySql的kill命令的内容。
在 MySQL 中有两个 kill 命令#xff1a;
一个是 kill query 线程 id#xff0c;表示终止这个线程中正在执行的语句#xff1b;一个是 kill connection 线程 id#…MySql的kill命令
Hi我是阿昌今天学习记录的是关于MySql的kill命令的内容。
在 MySQL 中有两个 kill 命令
一个是 kill query 线程 id表示终止这个线程中正在执行的语句一个是 kill connection 线程 id这里 connection 可缺省表示断开这个线程的连接当然如果这个线程有语句正在执行也是要先停止正在执行的语句的。
不知道你在使用 MySQL 的时候有没有遇到过这样的现象使用了 kill 命令却没能断开这个连接。再执行 show processlist 命令看到这条语句的 Command 列显示的是 Killed。显示为 Killed 是什么意思不是应该直接在 show processlist 的结果里看不到这个线程了吗
大多数情况下kill query/connection 命令是有效的。比如执行一个查询的过程中发现执行时间太久要放弃继续查询这时就可以用 kill query 命令终止这条查询语句。还有一种情况是语句处于锁等待的时候直接使用 kill 命令也是有效的。
一起来看下这个例子 可以看到session C 执行 kill query 以后session B 几乎同时就提示了语句被中断。这就是预期的结果。 一、收到 kill 以后线程做什么
但是停下来想一下session B 是直接终止掉线程什么都不管就直接退出吗
显然这是不行的。在全局锁和表锁中当对一个表做增删改查操作时会在表上加 MDL 读锁。所以session B 虽然处于 blocked 状态但还是拿着一个 MDL 读锁的。
如果线程被 kill 的时候就直接终止那之后这个 MDL 读锁就没机会被释放了。这样看来kill 并不是马上停止的意思而是告诉执行线程说这条语句已经不需要继续执行了可以开始“执行停止的逻辑了”。 其实这跟 Linux 的 kill 命令类似kill -N pid 并不是让进程直接停止而是给进程发一个信号然后进程处理这个信号进入终止逻辑。只是对于 MySQL 的 kill 命令来说不需要传信号量参数就只有“停止”这个命令。 实现上当用户执行 kill query thread_id_B 时MySQL 里处理 kill 命令的线程做了两件事
把 session B 的运行状态改成 THD::KILL_QUERY(将变量 killed 赋值为 THD::KILL_QUERY)给 session B 的执行线程发一个信号。
为什么要发信号呢因为像图 1 的例子里面session B 处于锁等待状态如果只是把 session B 的线程状态设置 THD::KILL_QUERY线程 B 并不知道这个状态变化还是会继续等待。
发一个信号的目的就是让 session B 退出等待来处理这个 THD::KILL_QUERY 状态。
上面的分析中隐含了这么三层意思
一个语句执行过程中有多处“埋点”在这些“埋点”的地方判断线程状态如果发现线程状态是 THD::KILL_QUERY才开始进入语句终止逻辑如果处于等待状态必须是一个可以被唤醒的等待否则根本不会执行到“埋点”处语句从开始进入终止逻辑到终止逻辑完全完成是有一个过程的。
到这里原来不是“说停就停的”。 看一个 kill 不掉的例子也就是在MySQL 实例健康状态检测方法中提到的 innodb_thread_concurrency 不够用的例子。
首先执行 set global innodb_thread_concurrency2将 InnoDB 的并发线程上限数设置为 2
然后执行下面的序列 可以看到
sesssion C 执行的时候被堵住了但是 session D 执行的 kill query C 命令却没什么效果直到 session E 执行了 kill connection 命令才断开了 session C 的连接提示“Lost connection to MySQL server during query”但是这时候如果在 session E 中执行 show processlist你就能看到下面这个图。 这时候id12 这个线程的 Commnad 列显示的是 Killed。也就是说客户端虽然断开了连接但实际上服务端上这条语句还在执行过程中。为什么在执行 kill query 命令时这条语句不像第一个例子的 update 语句一样退出呢
在实现上等行锁时使用的是 pthread_cond_timedwait 函数这个等待状态可以被唤醒。
但是在这个例子里12 号线程的等待逻辑是这样的每 10 毫秒判断一下是否可以进入 InnoDB 执行如果不行就调用 nanosleep 函数进入 sleep 状态。
也就是说虽然 12 号线程的状态已经被设置成了 KILL_QUERY但是在这个等待进入 InnoDB 的循环过程中并没有去判断线程的状态因此根本不会进入终止逻辑阶段。
而当 session E 执行 kill connection 命令时是这么做的
把 12 号线程状态设置为 KILL_CONNECTION关掉 12 号线程的网络连接。因为有这个操作所以你会看到这时候 session C 收到了断开连接的提示。
那为什么执行 show processlist 的时候会看到 Command 列显示为 killed 呢
其实这就是因为在执行 show processlist 的时候有一个特别的逻辑
如果一个线程的状态是KILL_CONNECTION就把Command列显示成Killed。
所以其实即使是客户端退出了这个线程的状态仍然是在等待中。那这个线程什么时候会退出呢答案是只有等到满足进入 InnoDB 的条件后session C 的查询语句继续执行然后才有可能判断到线程状态已经变成了 KILL_QUERY 或者 KILL_CONNECTION再进入终止逻辑阶段。 小结一下。这个例子是 kill 无效的第一类情况即线程没有执行到判断线程状态的逻辑。跟这种情况相同的还有由于 IO 压力过大读写 IO 的函数一直无法返回导致不能及时判断线程的状态。
另一类情况是终止逻辑耗时较长。这时候从 show processlist 结果上看也是 CommandKilled需要等到终止逻辑完成语句才算真正完成。这类情况比较常见的场景有以下几种
超大事务执行期间被 kill。这时候回滚操作需要对事务执行期间生成的所有新数据版本做回收操作耗时很长。大查询回滚。如果查询过程中生成了比较大的临时文件加上此时文件系统压力大删除临时文件可能需要等待 IO 资源导致耗时较长。DDL 命令执行到最后阶段如果被 kill需要删除中间过程的临时文件也可能受 IO 资源影响耗时较久。
如果直接在客户端通过 CtrlC 命令是不是就可以直接终止线程呢答案是不可以。
这里有一个误解其实在客户端的操作只能操作到客户端的线程客户端和服务端只能通过网络交互是不可能直接操作服务端线程的。而由于 MySQL 是停等协议所以这个线程执行的语句还没有返回的时候再往这个连接里面继续发命令也是没有用的。
实际上执行 CtrlC 的时候是 MySQL 客户端另外启动一个连接然后发送一个 kill query 命令。所以可别以为在客户端执行完 CtrlC 就万事大吉了。
因为要 kill 掉一个线程还涉及到后端的很多操作。 二、另外两个关于客户端的误解
1、如果库里面的表特别多连接就会很慢。
有些线上的库会包含很多表我见过最多的一个库里有 6 万个表。
每次用客户端连接都会卡在下面这个界面上。 而如果 db1 这个库里表很少的话连接起来就会很快可以很快进入输入命令的状态。因此有同学会认为是表的数目影响了连接性能。每个客户端在和服务端建立连接的时候需要做的事情就是 TCP 握手、用户校验、获取权限。但这几个操作显然跟库里面表的个数无关。
但实际上正如图中的文字提示所说的当使用默认参数连接的时候MySQL 客户端会提供一个本地库名和表名补全的功能。
为了实现这个功能客户端在连接成功后需要多做一些操作
执行 show databases切到 db1 库执行 show tables把这两个命令的结果用于构建一个本地的哈希表。
在这些操作中最花时间的就是第三步在本地构建哈希表的操作。所以当一个库中的表个数非常多的时候这一步就会花比较长的时间。也就是说感知到的连接过程慢其实并不是连接慢也不是服务端慢而是客户端慢。
图中的提示也说了如果在连接命令中加上 -A就可以关掉这个自动补全的功能然后客户端就可以快速返回了。
这里自动补全的效果就是你在输入库名或者表名的时候输入前缀可以使用 Tab 键自动补全表名或者显示提示。
实际使用中如果你自动补全功能用得并不多建议每次使用的时候都默认加 -A。
2、加–quick(或者简写为 -q) 参数也可以跳过这个阶段
但是这个–quick 是一个更容易引起误会的参数也是关于客户端常见的一个误解。
设置了这个参数可能会降低服务端的性能。为什么这么说呢MySQL 客户端发送请求后接收服务端返回结果的方式有两种
一种是本地缓存也就是在本地开一片内存先把结果存起来。如果你用 API 开发对应的就是 mysql_store_result 方法。另一种是不缓存读一个处理一个。如果你用 API 开发对应的就是 mysql_use_result 方法。
MySQL 客户端默认采用第一种方式而如果加上–quick 参数就会使用第二种不缓存的方式。
采用不缓存的方式时如果本地处理得慢就会导致服务端发送结果被阻塞因此会让服务端变慢。
为什么要给这个参数取名叫作 quick 呢
这是因为使用这个参数可以达到以下三点效果
第一点跳过表名自动补全功能。第二点mysql_store_result 需要申请本地内存来缓存查询结果如果查询结果太大会耗费较多的本地内存可能会影响客户端本地机器的性能第三点是不会把执行命令记录到本地的命令历史文件。
–quick 参数的意思是让客户端变得更快。 三、总结
这些“kill 不掉”的情况其实是因为发送 kill 命令的客户端并没有强行停止目标线程的执行而只是设置了个状态并唤醒对应的线程。而被 kill 的线程需要执行到判断状态的“埋点”才会开始进入终止逻辑阶段。
并且终止逻辑本身也是需要耗费时间的。所以如果发现一个线程处于 Killed 状态可以做的事情就是通过影响系统环境让这个 Killed 状态尽快结束。比如如果是第一个例子里 InnoDB 并发度的问题就可以临时调大 innodb_thread_concurrency 的值或者停掉别的线程让出位子给这个线程执行。而如果是回滚逻辑由于受到 IO 资源限制执行得比较慢就通过减少系统压力让它加速。
做完这些操作后其实已经没有办法再对它做什么了只能等待流程自己完成。 如果你碰到一个被 killed 的事务一直处于回滚状态你认为是应该直接把 MySQL 进程强行重启还是应该让它自己执行完成呢为什么呢 等。死等。 重启依然需要回滚完之后重启才能完成。若影响了其他线程可以进行主备切换。
