innodb_buffer_pool_size是唯一必须优先调优且配置错误易触发OOM的参数；需按物理内存减系统及其他进程占用后，取50%–75%并向下对齐至chunk×instances整数倍（如默认128MB×8=1024MB），单位用G或M，且必须置于[mysqld]段。
innodb_buffer_pool_size 是唯一必须优先调、且调错就可能被 OOM kill 的参数；其余参数都是围绕它协同工作的配角。别一上来就改 sort_buffer_size 或 join_buffer_size，那是在给内存泄漏打补丁。
怎么确认 MySQL 实际读的是哪个 my.cnf？
MySQL 不只读一个配置文件，而是按固定顺序加载所有存在的、可读的配置文件，后加载的覆盖前加载的。常见错误是改了 /etc/mysql/my.cnf，但实际生效的是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf（尤其在 Ubuntu apt 安装环境下）。
执行以下命令查看真实加载路径：
mysqld --verbose --help | grep -A2 "Default options"
更直接验证最终合并结果：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
my_print_defaults mysqld
- 如果输出里没看到你刚加的
innodb_buffer_pool_size，说明写错了文件或段落位置 - 检查是否误写在
[client]或[mysql]段——只有[mysqld]段里的配置才影响服务端 - RPM 安装默认走
/etc/my.cnf；apt 安装常通过!includedir /etc/mysql/mysql.conf.d/加载，主配置可能只是个壳
innodb_buffer_pool_size 怎么设才安全？
这个值不是“越大越好”，而是“大到不触发 OOM，又小到不频繁读盘”的平衡点。设错会直接导致 MySQL 被系统 OOM killer 杀掉，日志里留下 Killed process mysqld 这种无具体报错的静默死亡。
- 先算可用内存：物理内存总量 − OS 预留（至少 2–4G）− 其他进程（如 Redis、Nginx、Java 应用）占用
- 再取该值的 50%–75%，然后向下取整到
innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍（默认 chunk=128MB, instances=8 → 最小粒度 1024MB） - 单位必须写
12G或8192M，别写12884901888——重启失败时排查极困难 - 示例：64G 内存服务器，扣掉 8G 后剩 56G；56G × 62% ≈ 34.7G → 向下取整到 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，但需确认应用层连接池maxIdleTime或idleTimeout匹配 - 别信“连接数越多吞吐越高”——超过临界点后，线程上下文切换、锁争用、内存碎片反而拖垮性能
哪些 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 - 字符集相关：必须显式设
character-set-server = utf8mb4和collation-server = utf8mb4_unicode_ci，8.0 虽默认 utf8mb4，但某些发行版打包时仍可能回退
真正关键的不是参数多寡，而是 innodb_buffer_pool_size 是否落在安全区间、wait_timeout 是否与应用连接池对齐、以及有没有把已废弃参数留在配置里制造隐性故障。
