kill语句
kill不掉的第一种情况,innodb_thread_concurrency的上限了
- 用户在执行kill的时候,处理kill的线程做了两件事
- 把被kill的实例 的运行状态改成 THD::KILL_QUERY(将变量 killed 赋值为 THD::KILL_QUERY);
- 给 被kill的实例 的执行线程发一个信号。
- 一个语句执行过程中有多处“埋点”,在这些“埋点”的地方判断线程状态,如果发现线程状态是 THD::KILL_QUERY,才开始进入语句终止逻辑;
- 如果处于等待状态,必须是一个可以被唤醒的等待,否则根本不会执行到“埋点”处;
- 语句从开始进入终止逻辑,到终止逻辑完全完成,是有一个过程的。
- 所以kill并不是一执行就停止的
kill query pid
- 如果执行kill query pid,没有反应,有可能是被connection满了 被阻塞住了
- 而执行kill connection pid/kill pid,则是做了一下的操作
- 把pid的线程状态设置为kill_connection
- 断开pid的网络连接,所以pid在客户端就被断开了,实际上他在服务端还是处于等待的状态
终止逻辑耗时
- 有可能kill 不掉的另外一种情况:终止逻辑耗时,需要等终止逻辑结束才能kill掉这线程
- 超大事务中被kill,需要回滚这事务期间做的操作
- 大查询回滚:查询过程产生大的查询文件,碰上io资源紧张的话,耗时长
- DDL执行到最后被kill,则需要删除中间生成的临时文件,也有可能io资源紧张
客户端误解
表多连接慢
- 客户端在连接成功的时候,需要做一些操作
- show databases
- 切换到db,执行show tables
- 这两个命令构成了一个本地的哈希表(涉及库和表)
在第三步初始化的时候比较慢,可以加-a来跳过第三步.但是自动补全表名和库名就不生效了
加-query/-q的时候,有什么区别
- 跳过表名补全的功能
- mysql_store_result需要申请本地缓存来存储查询结果,本地缓存可能影响客户端的性能
- 不会把命令记录到本地的命令历史文件
所以加-q在客户端比较快,但是因为不用缓存,更容易造成阻塞(对服务端来说)等情况