MySQL 批量杀会话

MySQL的kill语法如下：

-- 可以查看帮助手册
help kill;
KILL [CONNECTION | QUERY] processlist_id;

KILL CONNECTION 与不带修饰符的 KILL 相同：它在终止连接正在执行的任何语句后终止与给定 processlist_id 关联的连接。会使对应的会话断开连接。 KILL QUERY 终止连接当前正在执行的语句，但保持会话连接。 processlist_id 可以通过 show [full] processlist 或者 performance_schema.threads 的 PROCESSLIST_ID 字段获取，也可以根据 information_schema.processlist 的 ID 字段获取。有的时候需要按照用户或者其他条件批量kill session 。可以参考以下语句：

SELECT GROUP_CONCAT(CONCAT('KILL ',id,';') SEPARATOR ' ') 'Paste the following query to kill all processes' FROM information_schema.processlist WHERE user<>'system user'\G

SELECT GROUP_CONCAT(CONCAT('KILL ',PROCESSLIST_ID,';') SEPARATOR ' ') 'Paste the following query to kill all processes' FROM performance_schema.threads WHERE PROCESSLIST_USER<>'system user'\G

需要注意的是，kill session 之后，线程可能需要一些时间才能死掉/结束，如果查询show processlist 的 Command 字段状态为 killed ，有可能是因为会话正在回滚。还有的情况是实例存在异常，可以检查 error log，如果 innodb_buffer_pool_size 设置过小，遇到过一次客户安装的时候采用的默认配置，innodb_buffer_pool_size 只有1G左右，整个服务器的内存16G，有点离谱。在 error log 中会提示如下错误

2024-07-04T10:35:05.757216+08:00 4736 [Warning] [MY-011959] [InnoDB] Difficult to find free blocks in the buffer pool (192308 search iterations)! 192308 failed attempts to flush a page! Consider increasing the buffer pool size. It is also possible that in your Unix version fsync is very slow, or completely frozen inside the OS kernel. Then upgrading to a newer version of your operating system may help. Look at the number of fsyncs in diagnostic info below. Pending flushes (fsync) log: 0; buffer pool: 0. 31142769 OS file reads, 77384027 OS file writes, 35847289 OS fsyncs. Starting InnoDB Monitor to print further diagnostics to the standard output.

将参数值调整之后很快就恢复正常，这里先不介绍该参数重点是怎么批量 kill session ，后续在讨论参数设置。