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 已移除，但老版本报告仍会提，你一搜教程发现全是过期方案。
