innodb_dedicated_server=on会自动配置innodb_buffer_pool_size、innodb_redo_log_capacity（8.0.30+）、innodb_flush_method三个参数，依据探测到的总内存静态计算，不考虑系统负载与其他进程，且该参数为只读启动项，修改后必须重启生效。
innodb_dedicated_server=ON 会自动改哪些参数？
它不是只调 innodb_buffer_pool_size，而是批量覆盖三个关键项：innodb_buffer_pool_size、innodb_redo_log_capacity（8.0.30+）、innodb_flush_method。其中 innodb_log_file_size 和 innodb_log_files_in_group 已被废弃，不再参与自动配置。
这些值全由 MySQL 启动时“探测到的总内存”推算，不查当前系统负载，也不管其他进程有没有在跑。比如你机器有 16GB 内存，但同时跑了 Java 应用占 6GB，它仍按 16GB 算 —— innodb_buffer_pool_size 就会被设成 12GB，极大概率触发 OOM。
- buffer pool 按规则：≤4GB 机器设为内存 × 0.5；＞4GB 设为 × 0.75
- redo log 容量依赖 buffer pool 大小，不是直接按物理内存算
-
innodb_flush_method强制设为O_DIRECT_NO_FSYNC，在某些 ext4/XFS 环境下需确认内核支持
怎么判断当前是不是“专用服务器”？
别凭感觉。真实混部场景包括：宝塔面板 + Nginx + PHP-FPM + MySQL 共存；K8s 节点上跑多个 Pod；宿主机里有定时备份脚本、日志采集 agent、监控 exporter —— 这些都算“非专用”。哪怕只多一个 Redis 实例，innodb_dedicated_server 就不该开。
唯一安全启用的场景是：MySQL 独占整台虚拟机/容器，且该 VM/容器不运行任何其他服务（含 cron、logrotate、syslog-ng 等基础组件也不建议共存）。
- Docker 场景：用
--memory=12g限制容器内存，并确保mysqld是容器内唯一长期进程 - K8s 场景：Pod 设置
resources.limits.memory，且不共享 node 上的其他数据库或中间件 - 云主机：若你买的是 RDS 或托管 MySQL，这个参数根本没得配 —— 云厂商已接管底层调优
开了之后发现 buffer pool 不合理，能动态关吗？
不能。SET GLOBAL innodb_dedicated_server = OFF 无效，该变量是只读启动参数，必须改配置文件并重启 mysqld 才生效。
常见误操作是：在 my.cnf 里写了 innodb_dedicated_server = OFF，但 MySQL 实际加载的是另一个路径（如宝塔写入 /www/server/mysql/my.cnf），结果重启后还是 ON —— 查真实加载路径用：ps aux | grep mysqld | grep defaults-file。
- 改完配置先校验：
mysqld --defaults-file=/path/to/my.cnf --verbose --help 2>/dev/null | head -5，不报错再重启 - 重启后立刻验证：
mysql -e "SHOW VARIABLES LIKE 'innodb_dedicated_server';" - 如果之前手动设过
innodb_buffer_pool_size，关掉 dedicated server 后，那个值才真正生效；否则它一直被覆盖
不开 dedicated server，buffer pool 怎么设才稳？
核心逻辑不是“占多少百分比”，而是“留多少给 OS 和其他进程”。16GB 机器别设 12G，10G 更稳妥；4GB 机器上限就是 1G，再高容易被 OOM killer 杀掉。
更关键的是对齐规则：innodb_buffer_pool_size 必须是 innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances 的整数倍，默认 chunk=128MB、instances=1，所以合法值只能是 128M、256M、384M……写 10G 可能被向下取整成 9.875G，悄无声息浪费内存。
- 查当前 chunk 和 instances：
SHOW VARIABLES LIKE 'innodb_buffer_pool%chunk%';、SHOW VARIABLES LIKE 'innodb_buffer_pool_instances'; - 计算合法值：比如 instances=8、chunk=128M → 最小步进是 1024M，那 10G 就非法，应设 10240M 或 9216M
- 上线前务必查空闲页占比：
SELECT (Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total) * 100 AS free_pct FROM performance_schema.global_status WHERE variable_name IN ('Innodb_buffer_pool_pages_free', 'Innodb_buffer_pool_pages_total');，长期 >25% 就说明设大了
实际最难把握的，是“专用”二字的边界 —— 很多团队以为关掉其他应用就算专用，却忽略了内核缓存、page cache、swap 预分配这些隐形竞争者。真要开，必须确认 MySQL 进程 RSS + page cache + swap usage 总和稳定低于物理内存。
