MySQLTuner是只读诊断工具，仅提供优化建议，不修改任何配置；所有my.cnf调整须手动完成，并需结合实际环境（如内存共用、存储引擎类型、慢日志状态等）审慎实施。

MySQLTuner跑完只给建议，不改配置

它只是个诊断工具，不是配置管理器。所有 my.cnf 修改必须手动完成，脚本本身从不碰你的配置文件。

常见错误现象：MySQLTuner 提示 max_connections 建议调到 512，但你直接在生产库上改完就重启，结果应用连不上——因为没同步更新连接池最大连接数，或者防火墙/代理层有限流。

• 先确认当前实际并发连接峰值：SHOW GLOBAL STATUS LIKE 'Threads_connected'; 和历史监控对比，别只看建议值
• key_buffer_size 只影响 MyISAM，如果你用的是 InnoDB（绝大多数情况），这个值再大也没用
• 修改前备份原 my.cnf，并用 mysqld --validate-config 检查语法（MySQL 5.7+ 支持）

“SLOW QUERIES”警告但慢日志没开

MySQLTuner 报 Slow queries: 1234 (X% of total)，但你查 slow_query_log 是 OFF，说明它其实是靠 Handler_read_rnd_next 等指标反推的估算值，不是真实慢日志统计。

这意味着：它提示“有慢查询”，但你根本拿不到具体是哪条 SQL。没开慢日志，等于没装行车记录仪，只告诉你“出过事故”，不告诉你谁撞的、怎么撞的。

• 先启用慢日志：SET GLOBAL slow_query_log = ON; + SET GLOBAL long_query_time = 1;
• 确保 log_output 包含 FILE（或 TABLE，但注意 mysql.slow_log 默认引擎是 CSV，查起来卡）
• MySQLTuner 的 Slow queries 行数值，在慢日志关闭时参考价值很低，别当真

内存建议值远超物理内存，别照抄

它算 max_allowed_packet、innodb_buffer_pool_size 时，常基于“假设你独占这台机器”，而现实里可能和 Redis、PHP-FPM、备份任务共存。直接按建议配，MySQL 启动失败是常态。

典型错误：报告说 innodb_buffer_pool_size 应设为 12G，你服务器总共才 16G 内存，结果 MySQL 启动后系统开始 OOM Kill 进程。

• 保守起见，InnoDB Buffer Pool 不要超过总内存的 70%，还要预留至少 2G 给 OS 和其他服务
• tmp_table_size 和 max_heap_table_size 必须设成相同值，否则大临时表会悄悄转磁盘
• 用 free -h 和 ps aux --sort=-%mem | head -5 看真实内存占用，比 MySQLTuner 的“理论可用内存”靠谱得多

基线数据得自己存，它不记历史

MySQLTuner 每次运行都是孤立快照，不保存上次结果，更不会画趋势图。你说“参数调了两周，性能反而变差”，它没法帮你比对。

这意味着：所谓“性能基线”，得你主动建个简单表，定期插入 mysqltuner 输出的关键字段（比如 Uptime、Questions、Slow_queries），否则基线就是一句空话。

• 加个 cron 每天跑一次：mysqltuner --user root --password 'xxx' --nocolor 2>/dev/null | grep -E "(Uptime|Questions|Slow_queries|Key_efficiency)" >> /var/log/mysqltuner.log
• 注意 --nocolor 必须加，否则输出带 ANSI 转义符，后续解析会乱
• 它不识别 Docker 或 cgroup 内存限制，容器里跑出来的内存建议值基本不可信

最麻烦的不是看不懂建议，而是它把“可调参数”和“该调参数”混在一起列——有些值压根不该动，比如 query_cache_type 在 MySQL 8.0 已移除，但老版本报告仍会提，你一搜教程发现全是过期方案。