pt-deadlock-logger无日志输出需检查dsn（如h=localhost,s=socket路径）和权限（select、process及目标表insert）；它依赖show engine innodb status，而该命令仅保留最后一次死锁，故须配合innodb_print_all_deadlocks=on（8.0.21+）或定期轮询+innodb_status_output_locks=on（5.7）才能获取完整上下文。
pt-deadlock-logger 启动后没日志输出？检查 DSN 和权限
常见现象是执行命令后终端无反应、日志文件为空，或报错 Access denied。根本原因通常是 DSN（数据源）写法错误或 MySQL 账户缺少必要权限。
- DSN 必须显式指定 socket 或 host+port：
h=localhost,S=/www/server/data/mysql.sock（宝塔默认用 socket）；仅写h=127.0.0.1可能因跳过 socket 导致连接失败 - 账户至少需具备：
SELECT权限（读取INFORMATION_SCHEMA.INNODB_TRX等视图）、PROCESS权限（查看线程状态），若写入目标表还需对应库表的INSERT - 宝塔环境下，root 密码不一定是系统 root 密码，而是面板中【数据库】→ 【MySQL】设置页显示的密码；若忘记，可在面板中重置并同步更新配置
死锁日志只记录最后一次？必须开启 innodb_print_all_deadlocks
pt-deadlock-logger 本身不捕获“所有”死锁——它轮询的是 SHOW ENGINE INNODB STATUS 输出，而该命令默认只保留最后一次死锁。真正决定能否记录全部死锁的，是 MySQL 服务端配置。
- 临时生效（重启失效）：
SET GLOBAL innodb_print_all_deadlocks = ON; - 永久生效：编辑宝塔中 MySQL 的配置文件（【软件商店】→ MySQL → 【设置】→ 【配置修改】），在
[mysqld]段落下添加：innodb_print_all_deadlocks = 1，然后【重启】服务 - 验证是否生效：
SHOW VARIABLES LIKE 'innodb_print_all_deadlocks';返回ON即可 - 注意：该参数会将死锁信息追加到 MySQL 错误日志（如
/www/server/data/mysql-error.log），不是慢查询日志
如何让 pt-deadlock-logger 持续后台运行并自动重连？
直接前台执行会阻塞终端，且网络抖动或 MySQL 重启会导致进程退出。生产环境必须用守护模式 + 自动恢复逻辑。
- 基础后台命令：
pt-deadlock-logger --log=/var/log/deadlock.log --daemonize --run-time=86400 --interval=5（每 5 秒查一次，持续 24 小时） - 更可靠的做法是配合 systemd 或宝塔计划任务：用脚本包装，每次启动前检查进程是否存在，不存在则重新拉起
- 关键参数说明：
--daemonize进入后台；--interval控制轮询间隔（太小加重负载，建议 ≥3s）；--run-time防止无限运行失控；--check可选，用于校验目标表结构 - 若写入数据库表，务必确认目标表已存在或加
--create-dest-table参数，否则工具静默失败
日志里只有时间戳和空行？锁监控未启用
即使死锁真实发生，pt-deadlock-logger 也可能只输出时间戳、无事务细节，这是因为 InnoDB 默认不输出详细锁信息。
- 必须启用锁监控：
SET GLOBAL innodb_status_output_locks = ON;（MySQL 5.6.16+ 支持） - 该参数影响
SHOW ENGINE INNODB STATUS的输出密度，尤其在LATEST DETECTED DEADLOCK块中补充lock_mode X locks rec but not gap等关键字段 - 宝塔中无法通过图形界面开关此参数，只能 SSH 执行 SQL 设置；注意它不写入 my.cnf，MySQL 重启后需重新执行（或加入启动脚本）
- 若使用
--dest写入数据库，确保目标表字段能容纳完整query内容（建议query TEXT，而非VARCHAR(255)）
innodb_print_all_deadlocks 是否真正生效、以及 innodb_status_output_locks 是否开启。缺一不可，否则看到的只是“有死锁发生”，但看不到“谁锁了谁、为什么锁”。
