innodb_buffer_pool_size不能设为128G，因需预留20–30GB给OS、内核及其他服务，否则易触发OOM；纯数据库服务器建议89G–96G，混部环境上限72G，并须同步配置instances、NUMA、连接内存等参数。
128GB内存的MySQL服务器，innodb_buffer_pool_size设到96G是常见且安全的起点，但必须配合innodb_buffer_pool_instances、NUMA和连接内存控制，否则反而可能触发OOM或性能抖动。
为什么innodb_buffer_pool_size不能直接设为128G？
MySQL不是唯一运行进程，操作系统、其他服务（如Nginx、PHP-FPM）、内核缓存都需要内存。硬塞满会导致系统频繁swap甚至被OOM Killer杀掉MySQL进程。实际可用缓冲池应预留至少20–30GB给OS和其他组件。
- 纯数据库服务器：建议设为物理内存的70%～75%，即89G～96G
- 混部环境（如LNMP共存）：建议上限72G，留足56G给系统与应用
- 必须确认
innodb_buffer_pool_instances同步调整——128GB内存下设为16个实例（每个约6GB），避免单实例锁争用 - 若服务器启用NUMA（多路CPU常见），需在
[mysqld]中加innodb_numa_interleave=ON，否则buffer pool可能只分配在单个NUMA节点上造成不均衡
max_connections和线程级缓冲不能按默认值线性放大
每个连接会独占sort_buffer_size、join_buffer_size等内存，1000个连接 × 4MB = 4GB额外开销。128GB内存不代表能无脑开高并发。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先用
SHOW STATUS LIKE 'Threads_connected';查真实峰值连接数，再设max_connections为该值的1.5倍（例如实测峰值600 → 设900） - 线程级参数保持保守：
sort_buffer_size = 2M、join_buffer_size = 2M、read_buffer_size = 1M；高并发下宁可让部分排序走磁盘，也不堆高内存 - 务必配
wait_timeout = 300和interactive_timeout = 300，防止空闲连接长期占内存
日志与临时表配置要匹配写入负载，而非一味调大
大内存不等于大日志就快。过大的innodb_log_file_size会延长崩溃恢复时间；过大的tmp_table_size可能让一个复杂JOIN吃掉数GB内存。
-
innodb_log_file_size建议设为innodb_buffer_pool_size的25%左右（例如96G buffer → 单个log file设2G，共2个，总4G） -
tmp_table_size和max_heap_table_size必须相等，设为512M足够应对绝大多数分析查询；超过此值自动转磁盘临时表，比OOM强得多 - 禁用已废弃的
query_cache_size（设为0），MySQL 5.7+该机制反而成为并发瓶颈 - 开启
slow_query_log并设long_query_time = 1，128G内存机器更应聚焦“慢查询优化”，而不是靠堆内存掩盖SQL缺陷
真正容易被忽略的是：改完my.cnf后，innodb_buffer_pool_size变更需要重启MySQL，而innodb_log_file_size变更还要求先删除旧log文件（ib_logfile0/ib_logfile1）——不删会导致启动失败，报错Incorrect log file size。别跳这步。
