pt-kill 误杀或漏杀源于仅依赖时间阈值而未区分合法长事务与真阻塞，需结合状态、命令、mdl锁及performance_schema截断问题综合判断，并辅以分层防御与进程健康监控。
长事务为什么会让 pt-kill 误杀或漏杀
pt-kill 的默认行为是按 --busy-time 或 --idle-time 判定“异常”，但数据库迁移（如用 mysqldump、pt-online-schema-change 或应用层双写）常产生长时间运行却合法的事务——比如一个正在写入千万级表的 INSERT ... SELECT，它 State 是 update，Time 可能超 30 分钟，但并非卡死。若只按时间阈值配置 pt-kill，容易把这类迁移事务当“慢查询”干掉，导致数据不一致或迁移中断。
关键在于区分「真阻塞」和「合法长耗时」：前者通常伴随 Waiting for table metadata lock、Locked 状态或高 trx_state = 'LOCK WAIT'；后者多为 Running 状态且 trx_operation_state 显示 inserting 或 reading event。
- 务必配合
INFORMATION_SCHEMA.INNODB_TRX和PROCESSLIST联查，不能只看Time字段 -
--match-command要排除常见迁移命令：例如--match-command="^(INSERT|UPDATE|REPLACE|LOAD DATA|ALTER TABLE)$"不够安全，应改用--ignore-command="INSERT|UPDATE|REPLACE|LOAD DATA"（注意 pt-kill 用的是正则匹配Command列） - 避免用
--kill直接终止，先用--print+--dry-run观察 10 分钟，确认匹配逻辑无误再启用
如何用 pt-kill 安全监控迁移中的 DDL 阻塞事务
DDL（尤其是 ALTER TABLE）在 MySQL 5.7+ 中虽支持 ALGORITHM=INPLACE，但仍可能因元数据锁（MDL）被长事务阻塞。此时真正该杀的是持有 MDL 的旧事务，而非正在执行 DDL 的线程本身。
典型现象：SHOW PROCESSLIST 中看到 DDL 线程状态为 Waiting for table metadata lock，而另一个线程状态为 Sleep 或 Query 且 Time 很大——这个才是元凶。
- 用
pt-kill --match-state="Sleep" --busy-time=600 --ignore-command="ALTER" --victims="all"捕获空闲超 10 分钟且非 ALTER 的连接（这些很可能是未提交事务的客户端） - 更精准做法：结合
--filter查 MDL 冲突源，例如：--filter='($event->{State} =~ /Sleep/ && $event->{Time} > 600) || ($event->{Info} =~ /^SELECT.*FROM.*WHERE.*FOR UPDATE/ && $event->{Time} > 300)' - 注意
pt-kill的--victims参数：设为oldest会杀最老连接（可能误伤），all更可控，但需确保不会批量断开应用连接
pt-kill 和 MySQL 8.0+ 的 performance_schema 冲突点
MySQL 8.0 默认开启 performance_schema，且部分版本（如 8.0.23+）中 events_statements_current 表对长事务的 SQL_TEXT 截断更激进（默认 1024 字节），导致 pt-kill 的 --match-info 匹配失效——你写的正则想匹配 INSERT INTO t1 SELECT ... FROM t2，结果查到的只有 INSERT INTO t1 SELECT ...，后面关键条件被截断了。
这不是 pt-kill 的 bug，而是底层采集粒度问题。
- 临时解决：调大
performance_schema_max_sql_text_length（需重启，且最大支持 1048576） - 更稳妥方式：改用
INFORMATION_SCHEMA.PROCESSLIST作为数据源，加参数--source=Processlist（pt-kill 默认用 Performance Schema） - 验证是否生效：运行
pt-kill --source=Processlist --print --limit=1，检查输出的Info字段是否完整包含你的迁移 SQL 片段
为什么不能只依赖 pt-kill 自动清理
pt-kill 是“响应式”工具，本质是轮询 + 杀线程，它无法感知事务语义。比如一个应用开启事务后执行了 5 条 INSERT，第 6 条卡住，pt-kill 杀掉后，前 5 条已提交的数据就变成脏数据；又或者迁移脚本用了 START TRANSACTION; ... COMMIT; 包裹整个流程，pt-kill 杀中间某条语句会导致事务回滚不完整。
真正可靠的方案是分层防御：
- 应用层：所有迁移操作必须设置
wait_timeout和interactive_timeout（建议 ≤ 600），并在代码里显式控制事务边界（避免隐式长事务） - 数据库层：开启
innodb_lock_wait_timeout=10（非全局锁等待，仅 DML 行锁），并定期查SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_migration_table%' - 运维层：pt-kill 只作为兜底，配置成每 30 秒扫描一次，且只杀
State = 'Locked' OR State = 'Waiting for table metadata lock'的线程，其他一律告警不杀
最易被忽略的一点：pt-kill 进程自身如果挂了、被 kill -9、或所在机器负载过高导致轮询延迟，监控就完全失效。必须配 systemd service + health check（例如用 pgrep -f "pt-kill.*--daemon" 做存活检测），否则你以为它在守着，其实早没动静了。
