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在客户端比较快,但是因为不用缓存,更容易造成阻塞(对服务端来说)等情况