我（嗯，我的 cron 脚本）试过killall mysqldump了，但结果并不好——mysql 服务器在一段时间后停止接受连接。
这是 Debian Jessie 机器，带有mysql 5.5.55-0+deb8u1.
使用场景是：
有一个长时间运行（几个小时）的
SELECT查询，要么真的很慢，要么发送它的客户端有问题（查询状态是Sending data），但所有其他查询都愉快地来来去去（只有负载可能略高） .在夜间备份正在运行
mysqldump --max_allowed_packet=2147483648 --hex-blob --single-transaction --master-data --routines --order-by-primary --databases db1 db2 db3... | pigz -p8 > backup.sql.gz。它从未完成，可能是因为它正在等待SELECT上面的首先完成（在这里猜测 - 这是唯一看起来不寻常的事情，并且相同的设置工作了几个月）。cron作业在早上运行，它
killall -q mysqldump应该安全地终止备份，以防它没有在设定的时间完成（通知管理员稍后检查并修复问题），从而允许人们继续正常使用mysql服务器。但是结果是完整的连接表，因此没有用户能够登录到 mysql 服务器。有
FLUSH /*!40101 LOCAL */ TABLES查询卡住Waiting for table flush，数百个SELECT查询卡在同一Waiting for table flush状态。此外，管理员杀死
LOCK TABLESmysql 查询并没有帮助，因为其他 SELECT 查询仍然存在Waiting for table flush（这似乎是预期的行为？）
重新启动 mysql 服务器终于“修复”了这个问题。但是，为了避免这种情况（和紧急管理员干预）重复，我想安全地终止 Debian Jessie mysql-5.5.55（或即将推出的 Debian Stretch mariadb-10.1.23-8）中的 mysqldump 备份。有办法吗？
如果没有，还有哪些其他选项可以完成 mysql 备份并避免早上的服务器负载（在这种情况下，这几乎与完全挂起的服务器一样糟糕）？
（如果可能的话，我想继续使用 Debian Stable 软件包）