1. 项目概述：为什么需要精准斩杀垃圾SQL？

在MySQL数据库运维的日常工作中，最令人头疼的莫过于那些突然出现的"垃圾SQL"——它们可能是开发人员临时测试忘记关闭的查询，也可能是未经优化的应用程序代码，甚至是被恶意注入的危险操作。这类SQL通常会长时间占用数据库连接，消耗大量CPU和内存资源，轻则导致系统响应变慢，重则引发整个数据库服务雪崩。

我经历过最严重的一次事故，某个凌晨3点被报警电话惊醒，线上核心业务数据库的CPU使用率飙升至98%，大量正常业务请求开始超时。紧急登录服务器排查后发现，一个报表系统生成的未加索引的聚合查询，竟然同时运行了37个相同实例。当时如果不知道pt-kill这个工具，恐怕只能选择重启数据库——这意味着至少30分钟的服务不可用。

Percona Toolkit中的pt-kill工具，就是专门为解决这类问题而生的"手术刀"。它不像粗暴的kill命令一刀切，而是支持基于执行时间、匹配模式、用户来源等数十种条件进行精准识别和清理。经过8年MySQL DBA生涯的验证，我可以肯定地说：这是每个数据库管理员工具箱里必备的利器。

2. 核心功能解析：pt-kill的杀手锏特性

2.1 智能匹配机制

pt-kill最强大的能力在于其灵活的匹配策略。与简单的SHOW PROCESSLIST+KILL组合相比，它支持多维度过滤条件：

# 匹配执行超过60秒的SELECT语句 pt-kill --busy-time 60 --match-command Query --match-state "Sending data" --victims all --kill # 针对特定用户发起的长时间操作 pt-kill --busy-time 120 --match-user 'report_user' --victims older --kill

实际运维中，我特别推荐使用--match-info参数配合正则表达式，这能精准锁定问题SQL模式。比如我们发现某个BI工具生成的查询都有/* BI_Tool_Query */注释，就可以用：

pt-kill --match-info '/\* BI_Tool_Query \*/' --busy-time 300 --kill

2.2 多模式运行策略

工具提供三种核心运行模式，适应不同场景：

1. 守护进程模式（最常用）：

   pt-kill --daemonize --interval 10 --print --log=/var/log/pt-kill.log \ --busy-time 60 --match-command Query --victims all --kill

   这个配置会每10秒检查一次，终止所有执行超过60秒的查询，并记录日志。

2. 定时任务模式： 适合在crontab中设置高峰期的保护策略：

   # 每天9-18点每5分钟检查一次 */5 9-18 * * * pt-kill --busy-time 120 --match-user 'webapp%' --kill

3. 交互式调试模式： 使用--print而不带--kill参数，先观察匹配结果：

   pt-kill --busy-time 30 --print --match-db 'orders'

重要提示：首次使用务必先用--print测试，确认匹配规则准确后再启用--kill。我有次误将--match-db写成--match-host，差点杀掉所有从库同步线程。

3. 实战配置详解：生产环境最佳实践

3.1 基础安全配置

在正式环境使用前，强烈建议创建专用账号并限制权限：

CREATE USER 'pt_kill_monitor'@'localhost' IDENTIFIED BY 'ComplexP@ssw0rd'; GRANT PROCESS, SUPER ON *.* TO 'pt_kill_monitor'@'localhost';

然后在pt-kill连接时使用这个专用账号：

pt-kill --user pt_kill_monitor --password ComplexP@ssw0rd --host localhost

3.2 多层级保护策略

根据我们的运维经验，建议设置三层防御：

1. 第一层：秒杀危险操作

   # 立即终止所有超过10分钟的查询 pt-kill --daemonize --interval 30 --busy-time 600 --kill

2. 第二层：业务定制规则

   # 终止报表用户超过5分钟的查询 pt-kill --daemonize --interval 60 --match-user 'report%' \ --busy-time 300 --kill --log=/var/log/pt-kill_report.log

3. 第三层：特殊保护白名单

   # 保护备份和复制线程 pt-kill --daemonize --interval 30 --busy-time 3600 \ --ignore-command 'Binlog Dump|Connect' --ignore-user 'repl_user'

3.3 高级匹配技巧

1. 识别锁等待：

   pt-kill --match-state 'Locked' --busy-time 30 --kill

2. 按数据量过滤：

   # 终止返回行数超过10万条的查询 pt-kill --rows-affected 100000 --kill

3. 正则表达式匹配：

   # 终止执行超过2分钟且包含特定表名的查询 pt-kill --busy-time 120 --match-info 'orders_\d{8}' --kill

4. 监控与日志分析

4.1 日志配置建议

启用详细日志记录对事后分析至关重要：

pt-kill --daemonize --interval 10 --log=/var/log/pt-kill.log \ --log-queries --print --busy-time 120 --kill

关键日志字段说明：

• Time: 杀进程的时间戳
• Host: 来源主机
• db: 数据库名
• Command: 命令类型
• Time_ms: 已执行时间
• State: 线程状态
• Info: SQL文本（前100字符）

4.2 日志轮转配置

在/etc/logrotate.d/下创建pt-kill文件：

/var/log/pt-kill.log { daily rotate 30 missingok notifempty compress delaycompress sharedscripts postrotate killall -HUP pt-kill endscript }

4.3 监控指标采集

建议将以下指标纳入监控系统：

1. 被杀进程数（按小时统计）
2. 平均执行时间超过阈值的查询比例
3. 高频被杀SQL模式TOP 10

可以用这个命令实时查看：

watch -n 60 "grep 'Killed' /var/log/pt-kill.log | awk '{print \$6}' | sort | uniq -c | sort -nr"

5. 典型问题排查指南

5.1 工具不生效的常见原因

1. 权限不足：

   SHOW GRANTS FOR 'pt_kill_monitor'@'localhost';

   确认有PROCESS和SUPER权限

2. 连接方式错误：

   # 错误：使用TCP连接本地可能触发skip-name-resolve问题 pt-kill --host 127.0.0.1 # 正确：使用socket连接 pt-kill --socket=/var/lib/mysql/mysql.sock

3. 时区不一致： 检查工具和MySQL服务器的时区设置：

   SELECT @@global.time_zone, @@session.time_zone;

5.2 误杀关键进程的应急处理

如果不慎杀掉了重要线程，立即检查MySQL错误日志：

tail -n 100 /var/log/mysql/error.log | grep -A 10 'Thread killed'

对于复制线程被误杀的情况，快速恢复步骤：

STOP SLAVE; START SLAVE; SHOW SLAVE STATUS\G

5.3 性能影响评估

pt-kill本身也会消耗资源，建议关注：

1. 工具进程的CPU占用（通常应<1%）
2. 连接频率（--interval不宜小于5秒）
3. 查询information_schema.processlist的耗时

可以用这个命令测试单次执行时间：

time pt-kill --run-time 1 --interval 1 --print

6. 进阶应用场景

6.1 与ProxySQL集成

将pt-kill与ProxySQL的查询规则结合使用：

INSERT INTO mysql_query_rules (rule_id,active,match_pattern,destination_hostgroup,apply) VALUES (100,1,'^SELECT.*FROM orders.*WHERE.*LIMIT \d+,\d+',10,1); # 然后在pt-kill中针对特定hostgroup进行监控 pt-kill --host 127.0.0.1 --port 6032 --user monitor --password xxx \ --busy-time 30 --match-hostgroup 10 --kill

6.2 自动生成kill防护规则

基于慢查询日志自动生成防护规则：

pt-query-digest /var/log/mysql/mysql-slow.log \ --filter '$event->{arg} =~ m/SELECT.*FROM large_table/' \ --output json | jq '.classes[].example.query' \ | xargs -I {} pt-kill --match-info "{}" --busy-time 30 --kill

6.3 在K8s环境中的部署

容器化部署方案（Dockerfile示例）：

FROM percona/percona-toolkit COPY pt-kill.cnf /etc/pt-kill/ CMD ["pt-kill", "--config=/etc/pt-kill/pt-kill.cnf"]

对应的ConfigMap配置：

apiVersion: v1 kind: ConfigMap metadata: name: pt-kill-config data: pt-kill.cnf: | [pt-kill] daemonize=1 interval=10 busy-time=120 kill=1 log=/var/log/pt-kill.log match-user=webapp%

7. 替代方案对比

虽然pt-kill非常强大，但也要了解其他类似工具的特点：

对于中小型环境，我推荐的这个Bash脚本也能应急：

#!/bin/bash while true; do mysql -u monitor -pXXX -e "SELECT id FROM information_schema.processlist WHERE COMMAND='Query' AND TIME > 60" -s | \ while read id; do echo "$(date): Killing $id" >> /var/log/mysql_killer.log mysql -u monitor -pXXX -e "KILL $id" done sleep 10 done

8. 性能优化建议

经过多年实践，总结出这些关键优化点：

1. 合理设置检测间隔：

   • 生产环境建议10-30秒
   • 测试环境可放宽到1-5分钟
   • 紧急情况下可临时调整为5秒

2. 优化匹配顺序： 把最可能命中的条件放在前面：

   # 优化前（每次都要检查所有条件） pt-kill --busy-time 60 --match-db 'report' --match-user 'webapp' # 优化后（先按用户过滤，范围更小） pt-kill --match-user 'webapp' --busy-time 60 --match-db 'report'

3. 避免过度杀伤： 设置分级保护，比如：

   • 普通查询：超过5分钟才杀
   • 已知危险模式：超过1分钟就杀
   • 特定用户查询：超过30秒就杀

4. 连接池配合： 在应用程序连接池中设置：

   # HikariCP配置示例 maximumPoolSize=50 maxLifetime=1800000 # 30分钟 idleTimeout=600000 # 10分钟

9. 安全防护措施

1. 网络隔离：

   • pt-kill只允许通过本地socket连接
   • 如果必须远程连接，限制源IP：

     GRANT PROCESS, SUPER ON *.* TO 'pt_kill_monitor'@'10.0.0.%';

2. 审计日志： 启用MySQL审计插件记录所有kill操作：

   [mysqld] plugin-load-add=audit_log.so audit_log_format=JSON audit_log_policy=ALL

3. 权限回收： 定期检查并回收不必要的SUPER权限：

   SELECT user,host FROM mysql.user WHERE Super_priv='Y';

4. 密码安全： 使用配置文件存储密码而非命令行：

   [client] user=pt_kill_monitor password=ComplexP@ssw0rd socket=/var/lib/mysql/mysql.sock

   然后设置文件权限：

   chmod 600 /etc/my.cnf.d/pt-kill.cnf

10. 真实案例复盘

10.1 电商大促期间的雪崩事件

去年双11期间，某电商平台在流量高峰时出现数据库响应缓慢。通过pt-kill日志分析发现，大量未使用索引的商品搜索查询堆积：

[2022-11-11 01:23:45] Killed 1843: User 'search_service' executing 'SELECT * FROM products WHERE title LIKE '%手机%' AND status=1' for 183 seconds

临时解决方案：

pt-kill --match-info 'LIKE \'%手机%\'' --busy-time 10 --kill

根本解决：事后为title字段添加全文索引，并修改查询方式。

10.2 数据仓库ETL任务阻塞

某金融机构的数据仓库在每月初跑批时经常阻塞核心交易。通过分析发现ETL任务没有设置合理的超时：

# 添加特殊规则保护ETL窗口 pt-kill --match-user 'etl_user' --busy-time 3600 --kill \ --except-time '00:00-06:00' --except-day-of-month '1-3'

10.3 开发环境失控查询

开发环境的测试库经常被跑垮，最终配置为：

pt-kill --match-host 'dev-db-%' --busy-time 300 --kill \ --memory-usage 1024M --ignore-user 'dba_admin'

11. 工具维护与升级

11.1 版本兼容性检查

Percona Toolkit版本需要与MySQL版本匹配：

检查当前版本：

pt-kill --version

11.2 定期规则评审

建议每季度审查一次kill规则，我使用的检查清单：

1. 统计各规则命中的频率
2. 验证最近30天误杀记录
3. 检查是否有新出现的慢查询模式
4. 评估检测间隔是否需要调整

11.3 备份与恢复策略

1. 备份配置文件：

   tar czf /backup/pt-kill-config-$(date +%F).tgz /etc/pt-kill/

2. 记录当前运行的命令：

   ps aux | grep pt-kill > /backup/pt-kill-process-$(date +%F).log

3. 恢复流程：

   # 停止现有进程 pkill pt-kill # 恢复配置 tar xzf /backup/pt-kill-config-2023-01-01.tgz -C / # 重新启动 pt-kill --config=/etc/pt-kill/pt-kill.cnf

12. 与监控系统集成

12.1 Prometheus监控配置

使用textfile收集器暴露指标：

#!/bin/bash TODAY_KILLS=$(grep -c "$(date +%F)" /var/log/pt-kill.log) echo "# HELP pt_kill_total Killed queries today" > /var/lib/node_exporter/pt-kill.prom echo "# TYPE pt_kill_total counter" >> /var/lib/node_exporter/pt-kill.prom echo "pt_kill_total $TODAY_KILLS" >> /var/lib/node_exporter/pt-kill.prom

然后添加到crontab：

*/5 * * * * /usr/local/bin/export-pt-kill-metrics.sh

12.2 Grafana仪表板

建议监控这些关键指标：

1. 按小时统计的kill操作次数
2. 被杀查询的平均执行时间
3. 按用户分类的kill分布
4. 按数据库分类的kill分布

对应的PromQL示例：

sum by (user) (increase(pt_kill_total{job="mysql"}[24h]))

12.3 告警规则配置

在Alertmanager中添加这些告警规则：

- alert: HighKillRate expr: rate(pt_kill_total[5m]) > 10 for: 10m labels: severity: warning annotations: summary: "High query kill rate on {{ $labels.instance }}" description: "{{ $value }} queries killed per minute"

13. 常见误区和正确实践

13.1 不要过度依赖pt-kill

常见反模式：

• 把pt-kill当作性能优化工具
• 不分析根本原因直接杀进程
• 设置过于激进的kill阈值

正确做法：

1. 先分析慢查询日志
2. 优化索引和SQL
3. 最后才用pt-kill作为保护措施

13.2 避免规则冲突

错误配置示例：

# 规则1：杀所有超过5分钟的查询 pt-kill --busy-time 300 --kill # 规则2：但允许报表查询运行10分钟 pt-kill --match-user 'report' --busy-time 600 --kill

这两个规则会冲突，应该改为：

pt-kill --busy-time 300 --ignore-user 'report' --kill pt-kill --match-user 'report' --busy-time 600 --kill

13.3 测试环境验证

新规则上线前应在测试环境验证：

1. 构造测试SQL

   SELECT SLEEP(100) FROM dual;

2. 观察pt-kill行为
3. 检查日志记录是否完整

14. 性能开销实测数据

在不同规模数据库上的测试结果：

测试方法：

# 监控pt-kill自身资源使用 pidstat -p $(pgrep pt-kill) -u -h 10 1

15. 工具内部原理剖析

了解pt-kill的工作原理有助于更好地使用它：

1. 连接管理：

   • 使用DBI连接到MySQL
   • 设置mysql_connect_timeout=3避免卡住

2. 进程列表获取：

   my $processlist = $dbh->selectall_arrayref("SHOW FULL PROCESSLIST");

3. 匹配引擎：

   • 按--busy-time过滤
   • 应用--match-*规则
   • 应用--ignore-*例外

4. kill执行：

   $dbh->do("KILL $thread_id");

5. 日志记录：

   • 使用Log::Dispatch记录到文件
   • 支持syslog集成

16. 自定义扩展开发

pt-kill支持插件扩展，常见开发场景：

1. 添加新的匹配条件：

   sub match_my_condition { my ($self, $process) = @_; return $process->{db} =~ /^shard_/; }

2. 自定义日志格式：

   local $Log::Log4perl::LOG_FORMAT = '[%d] [%p] %m%n';

3. 添加告警通知：

   sub after_kill { my ($self, $process) = @_; send_alert_email($process); }

编译安装自定义版本：

perl Makefile.PL make make install

17. 多数据中心部署方案

对于跨地域的数据库集群，建议这样部署pt-kill：

1. 中心化配置管理：

   • 使用Consul存储配置
   • 通过模板生成本地配置文件

2. 区域差异化配置：

   # 北美区域配置 pt_kill_config = { busy_time = 120 match_user = ["webapp_us"] } # 亚太区域配置 pt_kill_config = { busy_time = 180 match_user = ["webapp_asia"] }

3. 日志集中收集：

   # 使用Filebeat发送日志到ELK filebeat.inputs: - type: log paths: - /var/log/pt-kill.log fields: region: "asia-east1"

18. 与自动化运维平台集成

在运维平台中调用pt-kill的推荐方式：

1. API封装示例（Python）：

   def kill_long_queries(db_host, threshold): cmd = f"pt-kill --host {db_host} --busy-time {threshold} --print" result = subprocess.run(cmd.split(), capture_output=True) return parse_result(result.stdout)

2. Ansible集成：

   - name: Deploy pt-kill hosts: dbservers tasks: - name: Install Percona Toolkit apt: name=percona-toolkit state=present - name: Configure pt-kill template: src: pt-kill.conf.j2 dest: /etc/pt-kill.conf - name: Start pt-kill service systemd: name: pt-kill state: started enabled: yes

3. Terraform配置：

   resource "local_file" "pt_kill_config" { content = templatefile("${path.module}/templates/pt-kill.conf.tpl", { busy_time = var.busy_time_threshold }) filename = "/etc/pt-kill.conf" }

19. 历史版本功能对比

了解不同版本的功能差异：

升级测试步骤：

1. 在测试环境安装新版本
2. 并行运行新旧版本对比输出
3. 逐步切换生产环境实例

20. 资源消耗优化技巧

通过这些技巧可以降低pt-kill的资源占用：

1. 精简输出信息：

   pt-kill --busy-time 60 --kill --no-header --no-vertical

2. 限制检查范围：

   # 只检查特定数据库 pt-kill --match-db 'important_db' --busy-time 120

3. 调整连接参数：

   pt-kill --set-vars 'wait_timeout=5' --busy-time 60

4. 采样检查：

   # 每次随机检查50%的连接 pt-kill --sample 50 --busy-time 300

5. 使用轻量级输出：

   pt-kill --busy-time 60 --print --format '%T %u %h'

21. 特殊场景处理方案

21.1 批量导入保护

处理大型数据导入时：

pt-kill --busy-time 3600 --match-info 'LOAD DATA INFILE' --kill \ --except-time '02:00-04:00'

21.2 备份期间例外

为mysqldump添加保护：

pt-kill --busy-time 1800 --ignore-command 'Binlog Dump|Connect' \ --ignore-info 'mysqldump'

21.3 分布式事务处理

识别并保护XA事务：

pt-kill --busy-time 300 --ignore-state 'preparing' --kill

22. 相关工具链整合

pt-kill与其他Percona工具的配合使用：

1. pt-query-digest：

   # 分析慢查询日志生成kill规则 pt-query-digest /var/log/mysql-slow.log --filter '$event->{Query_time} > 10' \ | awk '/# Query/ {print "--match-info \"" $3 "\""}' > rules.txt

2. pt-mysql-summary：

   # 检查系统状态后决定是否启动pt-kill if pt-mysql-summary | grep -q 'Threads_running: [5-9][0-9]'; then pt-kill --busy-time 30 --kill fi

3. pt-stalk：

   # 在高负载时触发更严格的kill策略 pt-stalk --collect-trigger 'Threads_running > 100' \ --execute-command 'pt-kill --busy-time 15 --kill'

23. 企业级部署架构

对于大型企业环境，推荐这种部署模式：

[监控中心] | ├── [PT-Kill Master] ←→ [Consul配置中心] | | | ├─ [Region 1 Worker] | ├─ [Region 2 Worker] | └─ [Region 3 Worker] | └── [ELK日志中心] ←─ [所有PT-Kill实例]

关键组件：

1. 配置中心：统一管理所有规则
2. 主控节点：分发配置和收集状态
3. 区域Worker：执行实际的kill操作
4. 日志中心：集中存储和分析日志

24. 压力测试方法论

如何验证pt-kill在高负载下的表现：

1. 生成测试负载：

   -- 创建测试存储过程 DELIMITER // CREATE PROCEDURE generate_load(IN cnt INT) BEGIN DECLARE i INT DEFAULT 0; WHILE i < cnt DO SET @sql = CONCAT('SELECT SLEEP(', RAND()*100, ') FROM dual'); PREPARE stmt FROM @sql; EXECUTE stmt; SET i = i + 1; END WHILE; END // DELIMITER ; -- 在多个会话中执行 CALL generate_load(100);

2. 监控指标：

   # pt-kill响应时间 time pt-kill --run-time 10 --interval 1 --print > /dev/null # MySQL线程状态 mysqladmin -u monitor -p ext -i1 | grep Threads

3. 极限测试：

   # 模拟5000个连接 sysbench oltp_read_only --db-driver=mysql --mysql-host=127.0.0.1 \ --mysql-user=root --mysql-password= --mysql-port=3306 \ --tables=10 --table-size=100000 --threads=5000 --time=600 run

25. 法律与合规考量

在企业环境中使用pt-kill需要注意：

1. 审计要求：

   • 确保所有kill操作记录不可篡改
   • 日志至少保留180天
   • 包含操作者信息（通过--user参数）

2. 合规检查：

   • 不得终止合规要求的审计查询
   • 金融行业需保留完整的SQL上下文
   • 医疗行业需确保不影响关键事务

3. 权限分离：

   • 配置管理人员与执行人员分离
   • 实行双人复核制度
   • 关键规则变更需要审批

26. 性能调优实战记录

某电商平台的实际调优过程：

初始状态：

• 平均每5分钟kill 12个查询
• 95%的查询执行时间<2秒
• 但5%的查询执行时间>300秒

优化步骤：

1. 分析慢查询日志定位问题模式
2. 为高频被杀查询添加索引
3. 调整pt-kill规则：

   pt-kill --busy-time 10 --match-info 'FROM orders WHERE' --kill pt-kill --busy-time 30 --match-user 'webapp' --kill

4. 优化后效果：
   • kill操作降至每5分钟1-2次
   • 99%的查询执行时间<5秒
   • CPU使用率下降40%

27. 云数据库特别注意事项

在AWS RDS/Aurora等环境使用pt-kill：

1. 权限限制：

   • 云数据库通常限制SUPER权限
   • 需要使用特定参数：

     pt-kill --no-super --busy-time 60 --kill

2. 连接方式：

   # 使用IAM认证 pt-kill --host mycluster.cluster-123456.us-east-1.rds.amazonaws.com \ --user $IAM_TOKEN --password '' --ssl --ssl-verify-server-cert

3. 监控集成：

   • 将日志发送到CloudWatch
   • 设置基于kill次数的CloudWatch告警

4. Aurora特别配置：

   # 只处理读写实例 pt-kill --host mycluster.cluster-123456.us-east-1.rds.amazonaws.com \ --ignore-host '%ro-%' --busy-time 120

28. 安全审计与合规报告

生成合规报告的方法：

1. 每日kill汇总：

   grep 'Killed' /var/log/pt-kill.log | \ awk '{print $6}' | sort | uniq -c | \ sort -nr > /report/daily_kill_summary_$(date +%F).txt

2. 用户活动审计：

   SELECT user, COUNT(*) as kills, AVG(time_ms)/1000 as avg_sec FROM mysql_kill_audit WHERE kill_time > NOW() - INTERVAL 30 DAY GROUP BY user ORDER BY kills DESC;

3. 模式变化检测：

   # 比较本周与上周的高频被杀模式 diff <(grep -oP 'Info: \K.*' /var/log/pt-kill.log.1 | sort | uniq -c | sort -nr) \ <(grep -oP 'Info: \K.*' /var/log/pt-kill.log | sort | uniq -c | sort -nr)

29. 自动化测试套件

为pt-kill规则创建测试用例：

1. 测试框架示例（Python）：

   import unittest from mysql_kill_tester import PTKillTester class TestKillRules(unittest.TestCase): @classmethod def setUpClass(cls): cls.tester = PTKillTester(config='/etc/pt-kill.conf') def test_report_user_protection(self): result = self.tester.run_test( sql="SELECT * FROM large_report", user="report_user", expected="not_killed" ) self.assertTrue(result)

2. 测试场景：

   • 验证白名单功能
   • 测试阈值准确性
   • 模拟并发场景
   • 验证日志记录完整性

3. 持续集成：

   # GitHub Actions示例 jobs: test-pt-kill: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Test pt-kill rules run: | docker-compose up -d mysql pip install -r requirements.txt pytest tests/

30. 终极配置模板

经过多年实战检验的全功能配置模板：

[pt-kill] # 连接配置 user = pt_kill_monitor password = xxxxxx socket = /var/lib/mysql/mysql.sock # 基础参数 daemonize = 1 interval = 15 log = /var/log/pt-kill.log log-queries = 1 print = 1 # 全局保护规则 busy-time = 120 victims = all kill = 1 # 特殊保护规则 [rule1] match-user = report% busy-time = 600 kill = 1 [rule2] match-db = payment busy-time = 30 kill = 1 [rule3] ignore-command = Binlog Dump|Connect ignore-user = repl_user

使用方式：

pt-kill --config=/etc/pt-kill/full-featured.cnf

这个配置已经包含了我在金融、电商、游戏等行业积累的最佳实践，建议根据实际环境调整时间阈值和匹配规则。