pt-query-digest 读不出慢查询日志，需确认日志为 mysqld 生成的 FILE 格式、slow_query_log=ON、log_output=FILE，并检查权限、BOM、空格及实际写入状态。
pt-query-digest 读不出慢查询日志？检查日志格式和权限
MySQL 的慢查询日志必须是 mysqld 自己生成的文本格式（不是 JSON），且 slow_query_log_format = FILE。如果启用了 log_output = TABLE，pt-query-digest 默认完全无法读取 —— 它不支持从 mysql.slow_log 表解析。
常见错误现象：pt-query-digest /var/lib/mysql/slow.log 报错 No queries found，但用 tail -n 20 确实能看到日志内容。这时候大概率是日志里混入了非查询行（比如 # Time: 前面多了空格或 BOM）、或 MySQL 实际没在写日志（slow_query_log = OFF 被忽略）。
- 确认开启方式：必须同时设置
slow_query_log = ON、long_query_time = 1（或更低）、log_output = FILE - 检查文件权限：
pt-query-digest是以当前用户身份读文件，不是以mysql用户；确保该用户对日志路径有读权限 - 验证日志有效性：运行
head -n 50 /path/to/slow.log | grep "^# Time\|^SELECT\|^UPDATE"，看是否符合官方格式（时间戳行以# Time:开头，查询行顶格）
归档大表前必须关掉 binlog 写入？不一定，但得看归档方式
用 pt-archiver 归档历史数据时，是否禁用 sql_log_bin 取决于你是否需要保留主从一致性。它默认会写 binlog，所以从库也会执行归档删除 —— 这通常是你想要的；但如果只是清理单实例、或想避免主从延迟加剧，就得临时关闭。
容易踩的坑是直接在会话里执行 SET sql_log_bin = 0，结果发现没生效。因为 pt-archiver 默认用新连接执行 DELETE，老会话的变量不继承。
- 正确做法：加参数
--set-vars sql_log_bin=0，它会在每个连接初始化时设置 - 更安全的选择：用
--no-delete先导出数据，再手工清空，避开 binlog 风险 - 注意性能影响：关闭 binlog 后，归档过程不记日志，恢复困难；开启则可能拖慢主库，尤其在高写入场景下
归档后磁盘没释放？InnoDB 文件不会自动收缩
删掉几千万行后 du -sh 显示 ibdata1 或独立表空间文件大小不变，不是 pt-archiver 没删干净，而是 InnoDB 的数据页只标记为“可复用”，不返还给文件系统。
唯一能真正缩小 .ibd 文件的方法是重建表：OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB。但这会锁表、产生大量 IO，生产环境慎用。
- 如果用的是
innodb_file_per_table = ON（推荐），可对单表操作：ALTER TABLE orders ENGINE=InnoDB - 如果还是共享表空间（
ibdata1），基本无法收缩，只能导出 + 重装 MySQL - 日常预防：定期监控
DATA_LENGTH和DATA_FREE（查information_schema.TABLES），差值大说明碎片多
分析结果里 “Query_time” 和 “Lock_time” 差十倍？别急着优化 SQL
pt-query-digest 输出中，某条 SELECT 的 Query_time: 5.2s，但 Lock_time: 4.9s，说明它卡在等锁上，不是语句本身慢。这时候去加索引、改写 SQL 没用，得查谁在 hold lock。
典型使用场景：业务高峰期出现偶发性慢查，但 EXPLAIN 显示走索引、rows 很少。这时重点不是语句，是并发控制。
- 立刻查锁：登录 MySQL 执行
SELECT * FROM performance_schema.data_locks（8.0+）或SHOW ENGINE INNODB STATUS\G - 看事务持续时间：
information_schema.INNODB_TRX里的TRX_STARTED如果很早，说明长事务没提交 - 避免误判：
pt-query-digest --filter '$event->{Lock_time} > 0.5'可单独过滤高锁等待查询，聚焦问题类型
磁盘占用高的根因往往不在“数据量大”，而在“删不掉”“缩不了”“锁不住”。工具只是镜子，照出来的是设计和运维习惯的倒影。
