最核心的三件事是：用pt-variable-advisor摸清配置风险、用pt-table-checksum确认主从数据一致、用pt-query-digest盯住慢查询源头；这三步未落实前，其他优化均缺乏根基。
装完 MySQL 后直接上 Percona Toolkit 做巡检，最核心的三件事是：摸清配置风险、确认主从数据一致、盯住慢查询源头。其他工具可以往后排，这三步没走稳，后续优化都是空中楼阁。
pt-variable-advisor 检查 MySQL 配置合理性
很多性能抖动、连接数爆满、内存溢出，根源都在 my.cnf 里几个关键参数写错了。比如 innodb_buffer_pool_size 设成物理内存的 90%，或者 max_connections 留默认 151，上线后立刻扛不住。
- 必须用运行中的实例变量校验，不是只读配置文件：
pt-variable-advisor --defaults-file=/etc/my.cnf h=127.0.0.1,u=root,p=xxx - 重点关注 WARNING 和 CRITICAL 级别建议，比如 “
query_cache_sizeis deprecated in MySQL 8.0” 或 “tmp_table_sizeandmax_heap_table_sizemismatch” - 它不会改任何配置，但会指出哪些变量正在被忽略（例如你写了
sort_buffer_size，但实际生效的是 session 级值），这类信息容易被运维忽略
pt-table-checksum 校验主从数据是否已悄悄偏离
主从延迟高不等于数据不一致，但数据不一致往往在延迟恢复后才暴露——这时候业务可能已经写入错误数据。必须定期跑 pt-table-checksum，且只在主库执行。
- 先确保主库有
percona库：CREATE DATABASE percona;；否则工具会静默跳过所有表 - 必须加
--no-check-binlog-format，MySQL 8.0 默认binlog_format=ROW，不加这个参数会直接退出并报错 “Binlog format must be STATEMENT” - 权限不到位时错误提示极模糊，主库至少要给账号这些权限：
SELECT,INSERT,UPDATE,REPLICATION SLAVE,PROCESS,SUPER - 执行完立刻去从库查：
SELECT db,tbl,DIGEST,DIFFS FROM percona.checksums WHERE DIFFS != 0;—— 注意不是看 TS 或 CHUNKS，只认DIFFS列非零
pt-query-digest 分析慢查询日志定位真实瓶颈
光开慢日志没用，long_query_time=2 这种全局阈值对高并发小事务完全失灵。得靠 pt-query-digest 把日志里“藏得深”的问题挖出来，比如平均耗时才 80ms 但 P99 达到 2.3s 的查询。
- 先确认慢日志已启用且路径可读：
SHOW VARIABLES LIKE 'slow_query_log_file';，常见坑是日志路径权限不对，MySQL 写不进，pt-query-digest就只能分析空文件 - 按时间窗口切片比全量分析更实用：
pt-query-digest --since '2026-06-03 14:00:00' /var/lib/mysql/mysql-slow.log - 重点看报告末尾的 “Profile” 表格，其中
Rank列排序依据是响应时间占比，不是执行次数；排第一的未必是SELECT * FROM orders，很可能是某个被频繁调用的INSERT ... ON DUPLICATE KEY UPDATE - 如果日志里大量出现
Query_time: 0.000xxx，说明 MySQL 8.0 的 microsecond 级精度已开启，但旧版pt-query-digest可能解析异常，建议用 3.6.0+ 版本
真正难的不是跑通命令，而是理解每个工具的“作用边界”：比如 pt-table-checksum 只负责发现不一致，修复得交给 pt-table-sync；pt-variable-advisor 不告诉你怎么调参，只标出冲突和过时项。巡检不是一次性动作，而是把这三步固化进每周定时任务，并把输出结果中 CRITICAL 和 DIFFS != 0 这类信号接入告警通道——否则再准的诊断也等于没做。
