宝塔面板下真正生效的my.cnf路径是/www/server/mysql/etc/my.cnf，而非/etc/my.cnf；修改后必须在面板点击“保存”并重启MySQL，否则配置不生效，且需通过mysqld --validate-config校验语法、SHOW VARIABLES验证变量值。
确认宝塔面板下真正生效的 my.cnf 路径
直接改 /etc/my.cnf 基本无效——宝塔 5.7 实际读取的是 /www/server/mysql/etc/my.cnf。进宝塔 → 数据库 → 点击 MySQL 5.7 右侧“设置” → “配置修改”，打开的就是这个文件。改完必须点“保存”，否则只是编辑了内存里的副本，磁盘上没变。
常见错误：systemctl restart mysqld 没反应，或 SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; 显示值没变，八成是路径或没点保存。
针对 16 核 64G 服务器调关键内存参数
别套模板，按实际可用内存算：系统+PHP/Redis 至少留 8–10G，剩余约 54G 可分配给 MySQL。重点调三项：
-
innodb_buffer_pool_size = 36G：设为可用内存的 65% 左右，太高会触发系统 OOM Killer；太低则频繁刷盘 -
max_connections = 5000：每连接最低占 256KB，5000 连接 ≈ 1.2G 内存，够用且不浪费 -
innodb_log_file_size = 1G：必须等于innodb_buffer_pool_size的 25%～30%，但需先停 MySQL、删/var/lib/mysql/ib_logfile*再启动，否则报错InnoDB: Error: log file ib_logfile0 is of different size
绕过 query_cache 的坑和 thread_cache_size 设置
MySQL 5.7 默认禁用查询缓存：query_cache_type = 0，所以 query_cache_size 无论设多大都无效，还可能拖慢性能。删掉或注释掉这两行。
thread_cache_size 不是越大越好：
- 连接数
max_connections = 5000时，设thread_cache_size = 32就够用（经验公式：√max_connections，上限 32） - 设太大（如 128）反而增加线程管理开销，实测 QPS 下降 5%～8%
- 观察
Threads_created变化：持续增长说明 cache 不足；稳定在个位数说明已足够
日志与安全参数不能省略
大内存服务器常被误认为“资源富余”，但这些参数影响数据安全和故障恢复速度：
-
innodb_flush_log_at_trx_commit = 1：必须保持为 1，否则断电可能丢最近 1 秒事务；宝塔“一键优化”常偷偷改成 2，生产环境严禁 -
sync_binlog = 1：配合innodb_flush_log_at_trx_commit = 1，保证主从一致性 -
log_error_verbosity = 3：开启完整错误日志，便于排查连接超时、OOM 杀进程等隐性问题 -
table_open_cache = 4000和open_files_limit = 65535必须同步设，否则 MySQL 启动报Table cache is full
最后检查：改完重启前，先运行 mysqld --defaults-file=/www/server/mysql/etc/my.cnf --validate-config 验证语法；重启后立刻查 SHOW VARIABLES 确认值已生效，再盯 5 分钟错误日志有无 InnoDB: Cannot allocate memory 类报错——那是 buffer_pool 设太高了。
