innodb_buffer_pool_size 应根据 Discuz 热数据量设定，而非固定为内存70%；查三张核心表实际大小（如1200MB则设1.5G～2G），过大会触发OOM Killer导致502或MySQL崩溃。
innodb_buffer_pool_size 设多少才不翻车
直接说结论：innodb_buffer_pool_size 不该设成内存的 70% 或“推荐值”，而要看 Discuz 实际的热数据量。宝塔面板里盲目调高，反而会触发 Linux OOM Killer 杀 MySQL 进程——你发帖卡顿、后台报 MySQL server has gone away，大概率是这个原因。
Discuz 的热数据集中在 pre_forum_post、pre_forum_thread、pre_common_session 这三张表，尤其前两张带全文索引和频繁 INSERT/SELECT。用下面命令查真实占用：
SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'MB' FROM information_schema.tables WHERE table_schema = 'your_discuz_db' AND table_name IN ('pre_forum_post', 'pre_forum_thread', 'pre_common_session');结果若为 1200MB，那 innodb_buffer_pool_size 设 1.5G～2G 足够，再大就是浪费；若服务器只有 4GB 内存，硬塞 3G 进去，PHP-FPM 和 Nginx 就会抢不到内存，导致 502 错误频发。
宝塔里改配置后 MySQL 启不来的常见原因
在宝塔「数据库」→「配置修改」里改完 innodb_buffer_pool_size，点保存重启失败？不是语法错，而是三个隐藏条件没满足：
- 必须同时调大
innodb_log_file_size（至少为 buffer_pool 的 25%，否则 MySQL 拒绝启动） - 如果原来用的是默认
ib_logfile0/ib_logfile1，改完要先停 MySQL、手动删旧日志文件（路径通常是/www/server/data/），再启动，否则报错InnoDB: Error: log file ib_logfile0 is of different size - 宝塔的 MySQL 配置模板有时会漏掉
innodb_buffer_pool_instances，建议显式设为8（当 buffer_pool > 1G 时），避免内部锁争用影响并发发帖
Discuz 发帖变慢，光调 buffer_pool 没用的场景
用户点“发表”按钮转圈超过 3 秒，检查过 innodb_buffer_pool_size 合理，仍卡顿？重点看这三个地方：
-
pre_forum_post表缺失displayorder+dateline联合索引，Discuz 列表页和最新帖查询全表扫描，buffer_pool 再大也救不了 - 宝塔「计划任务」里启用了 Discuz 自带的「更新今日发帖数」定时脚本，它每分钟执行一次
UPDATE pre_common_stat SET... WHERE type='todayposts'，锁表严重——建议关掉，改用 Redis 缓存计数 - MySQL 的
sync_binlog设为1（宝塔默认开启），每次发帖都刷盘，SSD 都扛不住高并发写入；改成10或0（需接受主从延迟风险）可明显提速
验证优化是否生效的实操命令
别只看 phpMyAdmin 里的“运行中”状态，用这些命令确认真实效果：
查缓存命中率（稳定 > 99.5% 才算健康）：
SHOW ENGINE INNODB STATUS\G
往下翻找 Buffer pool hit rate 行，若长期低于 99%，说明 buffer_pool 还不够或索引不合理。
查发帖期间有没有行锁等待：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT';
如果有结果，结合 trx_query 字段看是不是卡在 INSERT INTO pre_forum_post —— 那就要回头检查 innodb_row_lock_time_avg 和索引设计了。
实际压测时，用 ab -n 100 -c 20 http://yourbbs.com/forum.php?mod=post&action=newthread&fid=2 模拟并发发帖，比看参数数字管用得多。
buffer_pool 是杠杆支点，但 Discuz 的性能瓶颈常在索引、锁、binlog 同步策略这些地方。调参前先看 slow_query_log 里有没有超 1 秒的发帖相关 SQL，比盲目加内存靠谱。
