innodb_buffer_pool_size是唯一必须优先调、且调错就可能被OOM kill的参数；其余参数都是围绕它协同工作的配角，关键需按可用内存（物理内存减系统及其他进程预留2–4GB）的50%–75%设定，并满足chunk×instances整数倍约束，单位写12G或8192M而非字节数。
直接说结论：innodb_buffer_pool_size 是唯一必须优先调、且调错就可能被 OOM kill 的参数；其余参数都是围绕它协同工作的配角。别一上来就改 sort_buffer_size 或 join_buffer_size，那是在给内存泄漏打补丁。
怎么确定 innodb_buffer_pool_size 的安全值？
这个值不是“越大越好”，而是“大到不触发 OOM，又小到不频繁读盘”的平衡点。关键看三件事：
- 物理内存总量减去 OS、其他进程（如 Redis、Nginx）、预留 buffer（至少 2–4G）后，剩下的才是 MySQL 可用内存
- 必须是
innodb_buffer_pool_chunk_size×innodb_buffer_pool_instances的整数倍（默认 chunk=128MB，instances=8 → 最小粒度 1024MB）。设 11G 会自动向下取整为 10G，还报 warning - 单位写
12G或8192M，别写12884901888这种字节数——易错、难读、重启失败时排查困难
示例：64G 内存服务器，扣掉 8G 给系统和其他服务，剩 56G。按 62% 算 ≈ 34.7G → 向下取整到最接近的 1024MB 倍数 = 34G（即 34816M），写成 innodb_buffer_pool_size = 34G 即可。
max_connections 和 wait_timeout 为什么必须一起调？
只调 max_connections 是假扩容。每个连接默认分配 sort_buffer_size（256K–2M）、join_buffer_size（256K 起）、thread_stack（256K），并发 2000 连接光线程级内存就可能吃掉 4–6G —— 这部分不随查询结束立刻释放，得等连接断开。
-
wait_timeout控制非交互式连接（如 JDBC）空闲多久断开；interactive_timeout控制 mysql client 连接。二者必须设成相同值，否则 CLI 会话行为异常 - 生产环境建议
max_connections = 2000+wait_timeout = 300（5 分钟）。高并发短连接场景可压到 120，但需确认应用层连接池配置匹配 - 别信“连接数越多吞吐越高”——超过临界点后，线程上下文切换、锁争用、内存碎片反而拖垮性能
哪些参数在 MySQL 8.0 里已经失效或改名了？
拿 5.7 的 my.cnf 直接覆盖到 8.0，90% 概率启动失败。常见踩坑点：
-
query_cache_type/query_cache_size：MySQL 8.0 彻底移除，设了会报 unknown variable 错误 -
innodb_log_file_size：8.0.30+ 已被innodb_redo_log_capacity取代；老参数仍可读，但不生效 -
innodb_large_prefix：8.0 默认启用，无需配置；设为 OFF 会报 warning -
log_bin开关方式变了：不再支持log_bin = OFF，要禁用 binlog 得删掉整行或注释掉
验证方法：改完配置后，先跑 mysqld --defaults-file=/path/to/my.cnf --verbose --help 2>/dev/null | head -5，不报错再重启；重启后执行 mysql -e "SHOW VARIABLES LIKE 'innodb_redo_log_capacity';" 看是否生效。
为什么改了 my.cnf 但 SHOW VARIABLES 里没变？
90% 是因为 MySQL 根本没读你改的那个文件。它按固定顺序加载：/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删掉或重命名，要么在/etc/my.cnf里加一行!include /www/server/mysql/my.cnf（MySQL 8.0.14+ 支持） - 改完别急着重启，先用
mysqld --defaults-file=xxx --validate-config（8.0.16+）校验语法，比靠日志猜强得多
最常被忽略的一点：缓冲池大小变更后，首次启动会做 warmup，Innodb_buffer_pool_read_requests 在前几分钟内偏低是正常的，别刚重启就 panic。
