pt-kill默认仅打印不杀，必须显式加--kill或--kill-query才生效；需配--busy-time设阈值，且用户须有process+connection_admin权限；应配合--ignore-和--match-精准过滤，避免误杀复制或监控线程，并通过--interval、--log和--victims all实现生产级稳定运行。
直接用 pt-kill 杀慢查询不是配完参数就自动生效的——它默认只打印、不杀，必须明确告诉它“动手”，还得确保权限、过滤和运行方式都到位。核心是：先精准识别，再安全终止。
必须加 --kill 或 --kill-query 才真正生效
很多用户跑完命令发现慢查询还在跑，问题就出在这里：pt-kill 默认是 --print 模式，纯观察，不执行任何 kill 操作。
- --kill：终止整个连接（含当前正在执行的语句 + 后续可能复用的会话）
- --kill-query：只中断当前 SQL 语句，连接保持活跃（适合应用有重试逻辑的场景）
- 两者都必须配合 --busy-time N（单位秒）指定超时阈值，例如
--busy-time 30表示查杀已执行超 30 秒的线程
权限不能少：PROCESS + SUPER 或 CONNECTION_ADMIN
没权限，命令执行成功也杀不动——这是最常见失败原因。
- MySQL 5.7 及以前：需 PROCESS + SUPER 权限
- MySQL 8.0+：SUPER 已弃用，必须用 PROCESS + CONNECTION_ADMIN（若启用角色模型，还需确认该用户被赋予对应角色）
- 不建议用 root；应建专用账号，例如：
GRANT PROCESS, CONNECTION_ADMIN ON *.* TO 'ptkiller'@'localhost';
FLUSH PRIVILEGES;
避免误杀：用 --ignore-* 和 --match-* 精准圈定目标
不加过滤，Binlog Dump、pt-heartbeat、监控工具连接等常被一并干掉，导致主从中断或告警失灵。
- 排除复制线程：--ignore-command="Binlog Dump,Change master,Start slave"
- 排除运维/监控用户：--ignore-user="monitor,backup,pt-heartbeat,dba"
- 只针对真实业务查询：--match-command="Query" --match-state="executing|Sending data|Sorting result"
- 进一步限定 SQL 类型（如只杀 SELECT）：--match-info="^(SELECT|UPDATE|DELETE|INSERT)\b"（注意转义词界）
生产可用的关键运行配置
长期驻守线上，不能只靠手动执行一次，得稳、可查、低干扰。
-
--interval 5~10：每 5–10 秒轮询一次
INFORMATION_SCHEMA.PROCESSLIST；太小（如 1s）加重主库压力，太大（如 30s）可能让慢查询多跑半分钟 - --log /var/log/pt-kill.log：必须加！所有 kill 行为、线程 ID、SQL 片段都会记录，故障回溯全靠它
-
--victims all：默认只杀最老的一个（
oldest），生产建议设为all，一次性清理全部超时查询 - 守护进程化：--daemonize（后台运行）或配合 systemd/nohup；不加
--run-time即长期运行
