MySQL 8.0.32 跑在 8 核 16G 的 ECS 上，按官方建议开了 innodb_dedicated_server，实例起来后 buffer pool 吃到十三 G，系统开始用 swap，接口 P99 从十毫秒涨到两百毫秒。
一开始怀疑是「redo log 容量也被自动放大，落盘和崩溃恢复时间跟着变长」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。这个参数按物理内存的七成五算 buffer pool，没给系统和其他进程留余量。另一种情况是同一台机器上还跑着 PHP-FPM 和 Redis，内存被三方分掉。
不容易想到的是，开启后手工写的 innodb_buffer_pool_size 会被忽略，以为改小就能生效。
先看实际生效的三个值
mysql -e "SELECT @@innodb_buffer_pool_size/1024/1024 AS bp_mb, @@innodb_log_file_size/1024/1024 AS log_mb, @@innodb_dedicated_server"再往下确认有没有已经在用 swap
free -m && vmstat 1 3接着关掉自动推算并写死 buffer pool
mysql -e "SET GLOBAL innodb_buffer_pool_size=6442450944"等前面都确认过，再确认配置文件里的持久化项
grep -rn 'innodb_buffer_pool_size' /etc/my.cnf.d/别只看报错消失，验证要多做一步。buffer pool 稳定在六 G，free 里 available 留出四 G 以上，si so 归零，接口 P99 回到二十毫秒以内。
容易忽略的是，dedicated_server 适合独占整机的数据库，混部环境一定要手动定值；它在启动时按内存推算，运行中改全局变量只对当前实例有效。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。