innodb_buffer_pool_size必须第一个调，设错直接OOM；安全值=物理内存－OS及其他进程占用－2~4GB缓冲，再向下取整为chunk_size×instances的整数倍（如128MB×8=1024MB），示例64GB服务器得34G。
innodb_buffer_pool_size 必须第一个调，设错直接被 OOM kill；其他参数全是配角，别一上来就动 sort_buffer_size 或 join_buffer_size。
怎么算出安全的 innodb_buffer_pool_size 值
这个值不是“越大越好”，而是要避开 OOM 又不频繁读盘。关键看三件事：
- 物理内存总量减去 OS、Redis/Nginx 等其他进程占用，再预留 2–4GB 缓冲
- 结果必须是
innodb_buffer_pool_chunk_size×innodb_buffer_pool_instances的整数倍（默认 chunk=128MB，instances=8 → 最小粒度 1024MB） - 单位写
12G或8192M，别写12884901888这种字节数——重启失败时根本没法快速定位
示例：64GB 服务器，扣掉 8GB 给系统和其他服务，剩 56GB。按 62% 算≈34.7G → 向下取整到最接近的 1024MB 倍数 = 34G（即 34816M），配置就写 innodb_buffer_pool_size = 34G。
为什么改了 my.cnf 内存还是没降下来
90% 是 MySQL 根本没读你改的那个文件。MySQL 8.0 按固定顺序加载配置：/etc/my.cnf → /etc/mysql/my.cnf → /usr/etc/my.cnf → ~/.my.cnf，而宝塔、AMH 等面板常把配置写进 /www/server/mysql/my.cnf ——这个路径不在默认列表里。
实操步骤：
- 查真实加载路径：
ps aux | grep mysqld | grep -o '\-\-defaults-file=[^ ]*'，没输出说明走默认路径 - 删或重命名
/etc/my.cnf（如有），再改面板写入的路径（如/www/server/mysql/my.cnf） - 改完先校验语法：
mysqld --defaults-file=/www/server/mysql/my.cnf --verbose --help 2>/dev/null | head -5，不报错才重启 - 重启后验证：
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
max_connections 和 wait_timeout 必须一起调
只调 max_connections 是假扩容。每个连接默认分配 sort_buffer_size（256K–2M）、join_buffer_size（256K 起）、thread_stack（256K），并发 2000 连接光线程级内存就可能吃掉 4–6GB ——这部分不随查询结束立刻释放，得等连接断开。
注意点：
-
wait_timeout控制 JDBC 等非交互式连接空闲多久断开；interactive_timeout控制mysqlCLI 连接；二者必须设成相同值，否则 CLI 会话行为异常 - 生产环境建议
max_connections = 2000+wait_timeout = 300（5 分钟）；高并发短连接场景可压到120，但需确认应用层连接池 idle timeout 配置匹配 - 别信“连接数越多吞吐越高”——超过临界点后，线程上下文切换、锁争用、内存碎片反而拖垮性能
最容易被忽略的是：MySQL 8.0 已彻底移除 query_cache_type 和 query_cache_size，写了会报 unknown variable 错误；innodb_log_file_size 在 8.0.30+ 已被 innodb_redo_log_capacity 取代，老参数仍可读但不生效。这些不是“优化项”，是启动前必须清理的雷。
