MySQL 5.7 在宝塔面板下实际生效的配置文件是 /www/server/mysql/etc/my.cnf，而非 /etc/my.cnf；修改后须在面板点击“保存”，并验证语法、变量值及错误日志。
MySQL 5.7 配置文件在哪？改之前必须确认路径
宝塔面板下，my.cnf 实际由两部分组成：主配置在 /etc/my.cnf，但宝塔会额外加载 /www/server/mysql/etc/my.cnf（或类似路径，取决于安装方式）。直接改 /etc/my.cnf 可能被宝塔后台覆盖；真正生效的是宝塔管理的那份。进宝塔 → 数据库 → 点击 MySQL 5.7 行右侧“设置” → “配置修改”，这里打开的就是实际生效的配置文件。
常见错误：手动编辑 /etc/my.cnf 后重启 MySQL 没效果，就是因为宝塔没读它。还有的用户改了配置但忘记点击面板上的“保存”按钮——宝塔不会自动写入磁盘，必须点保存才落盘。
根据内存大小选关键参数：buffer_pool、max_connections、query_cache
MySQL 5.7 已禁用 query_cache_type=0（默认），别再调 query_cache_size，它无效且可能拖慢性能。重点看三项：
-
innodb_buffer_pool_size：设为物理内存的 50%–75%，但必须 ≤ 服务器总内存减去系统和 PHP/Redis 等其他服务所需。例如 4GB 内存服务器，PHP-FPM 占约 0.8GB，留 0.5GB 给系统，剩余约 2.7GB，可设innodb_buffer_pool_size = 2G； -
max_connections：别盲目设 1000+。真实并发远低于此值，高设置反而增加内存开销（每个连接至少占用 256KB）。1GB 内存机器建议 ≤ 150，4GB 建议 ≤ 300； -
innodb_log_file_size：影响写性能与崩溃恢复时间。5.7 默认是 48MB，若innodb_buffer_pool_size > 1G，建议配成 buffer_pool 的 25%（如 2G buffer_pool → log_file_size = 512M），但需先停 MySQL、删旧ib_logfile*文件再启动，否则报错。
宝塔“一键优化”按钮到底干了什么？能不能信
宝塔的“性能优化”按钮（在 MySQL 设置页）本质是按预设规则重写 my.cnf，但它不识别你的业务类型（比如你是 WordPress 还是 ERP）、不感知当前慢查询量、也不检查磁盘 I/O 能力。它只做三件事：调大 innodb_buffer_pool_size、增大 max_connections、启用 skip-name-resolve。对小站可能有用，但对高并发写入场景，它把 innodb_flush_log_at_trx_commit=1（强一致性）改成 2 或 0，会导致断电丢事务——这点面板从不提示。
实操建议：不要直接点“一键优化”，而是点“配置修改”，对照自己内存和业务负载手工调整。尤其生产环境，innodb_flush_log_at_trx_commit 必须保持 1，除非你明确接受丢失最近 1 秒事务的风险。
改完配置后必须做的三件事
改完不是点保存就完事。漏掉任一环节都会导致性能不升反降：
- 检查语法：执行
mysqld --defaults-file=/www/server/mysql/etc/my.cnf --verbose --help | grep "Default options"，确认无报错； - 验证生效：登录 MySQL 执行
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，数值必须和你写的完全一致（注意单位是字节，2G显示为2147483648）； - 观察日志：重启后立刻查
/www/server/mysql/logs/error_log，留意是否有InnoDB: Cannot allocate memory或Could not increase number of max_open_files类错误——前者说明 buffer_pool 设太大，后者需同步调大系统限制（ulimit -n和/etc/security/limits.conf）。
最常被忽略的是第三点：很多“优化后变卡”的案例，其实是因为 open_files_limit 不足，MySQL 被迫频繁关闭/重建表句柄，CPU 暴涨却查不到慢 SQL。
