pt-kill 实现生产 sql 熔断需闭环落地四层面：权限（专用账号+process/connection_admin）、识别（限定query/执行态/排除干扰）、熔断（按连接池选kill-query或kill+busy-time）、运维（interval/日志/daemonize+上线前print验证）。
要用 pt-kill 实现生产环境 SQL 耗时熔断，关键不是“一杀了之”，而是建立可验证、可收敛、不误伤的自动防御机制。它本质是一套带规则引擎的实时监控+精准干预系统，需从权限、识别、执行、运维四个层面闭环落地。
权限配置：先让工具“有资格动手”
没权限，命令跑再多次也无效——这是最常被忽略的前提。
- MySQL 5.7 及以前：必须同时授予 PROCESS + SUPER 权限
- MySQL 8.0+：SUPER 已废弃，必须用 PROCESS + CONNECTION_ADMIN（若启用角色模型，还需显式赋予该角色）
- 禁止直接用 root；应创建专用账号，例如：
CREATE USER 'ptkiller'@'localhost' IDENTIFIED BY 'StrongPwd2026!';
GRANT PROCESS, CONNECTION_ADMIN ON *.* TO 'ptkiller'@'localhost';
FLUSH PRIVILEGES;
精准识别：只盯住真正危险的 SQL
默认查杀范围太宽，极易误杀 Binlog Dump、监控连接或心跳线程，导致主从断裂或告警失灵。
- 基础过滤：限定只处理业务查询类线程 → --match-command="Query"
- 状态聚焦：只捕获正在真实执行的语句 → --match-state="executing|Sending data|Sorting result|Copying to tmp table"
- 排除高危干扰项：
--ignore-command="Binlog Dump,Change master,Start slave"
--ignore-user="monitor,backup,pt-heartbeat,dba" - 按业务类型收口（如只熔断 SELECT）→ --match-info="^(SELECT|UPDATE|DELETE|INSERT)\b"（注意词界转义）
安全熔断：区分“停语句”和“断连接”
是否保留连接，取决于应用是否有重试或连接池逻辑。
- --kill-query：仅中断当前 SQL，连接保持活跃 → 适合使用 HikariCP、Druid 等主流连接池的应用
- --kill：终止整个连接（含会话上下文）→ 适合无重试机制或需强制释放资源的场景
- 必须搭配 --busy-time N（单位秒），例如 --busy-time 15 表示熔断已执行超 15 秒的语句
- 避免单次只杀一个 → 显式指定 --victims all，防止漏杀并发慢查询
生产就绪：稳态运行与可观测性
不能靠人工敲一次命令，得让它像守护进程一样长期可靠工作。
- 轮询频率合理：用 --interval 8（8 秒检查一次），太密加重主库压力，太疏导致熔断延迟
- 必须落盘日志：--log /var/log/pt-kill-slow.log，所有被熔断的线程 ID、SQL 片段、时间戳全记录，故障回溯唯一依据
- 后台常驻：--daemonize 启动为守护进程，配合 systemd 或 supervisor 管理生命周期
- 上线前必走验证流程：先用 --print 模式运行 10 分钟，确认匹配结果符合预期，再切到 --kill-query 或 --kill
