MySQL 8.0在Docker中动态修改innodb_buffer_pool_size需满足：变量SCOPE为GLOBAL且IS_DYNAMIC为YES，用户具备SYSTEM_VARIABLES_ADMIN权限，并同步更新配置文件防重启失效。
MySQL 8.0 在 Docker 容器中默认不允许动态修改部分关键系统变量（如 innodb_buffer_pool_size、max_connections），除非满足特定条件——你必须确认该变量支持运行时修改，且容器内 MySQL 是以非只读方式启动的。
确认变量是否支持动态修改
不是所有系统变量都能在线调整。执行 SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'innodb_buffer_pool_size'; 查看 VARIABLE_SCOPE 字段：若为 GLOBAL 且 IS_DYNAMIC 为 YES，才可 SET；若为 SESSION 或 STATIC，必须重启生效。
常见误区：sort_buffer_size 支持 SESSION 级修改，但 innodb_log_file_size 属于 STATIC，强行 SET 会报错 ERROR 1238 (HY000): Variable 'innodb_log_file_size' is a read only variable。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 查支持动态的变量：运行
SHOW VARIABLES LIKE '%buffer%';后，再查performance_schema.variables_info - 避免在连接池复用场景下只改 SESSION 变量——下次获取连接可能重置
- Docker 中通过
mysql -u root -p -e "SET GLOBAL innodb_buffer_pool_size=2147483648;"执行时，需确保用户有SYSTEM_VARIABLES_ADMIN权限
绕过只读容器文件系统的限制
Docker 默认挂载的 /var/lib/mysql 是可写的，但 MySQL 8.0 的某些配置（如 innodb_page_size）写入后会触发校验失败，导致 mysqld 拒绝启动。更常见的是：你修改了 my.cnf 并重启容器，却发现变量没生效——大概率是配置文件未被 MySQL 加载，或被命令行参数覆盖。
- 检查实际加载的配置路径：
docker exec -it mysql8 mysql -uroot -p -e "SELECT @@config_file;"（MySQL 8.0.21+ 支持） - 推荐做法：用
docker run启动时通过--config-file=/etc/mysql/conf.d/custom.cnf显式指定，而非依赖 /etc/mysql/my.cnf - 如果使用
mysql:8.0官方镜像，/etc/mysql/conf.d/ 下的 *.cnf 文件会被自动加载，优先级高于主配置
安全修改 global 变量的实操要点
即使变量支持动态修改，也需注意副作用。例如增大 innodb_buffer_pool_size 可能立即占用更多内存，而容器未设置 --memory 限制时，OOM Killer 可能杀掉 mysqld 进程。
- 先查当前值：
SELECT @@global.innodb_buffer_pool_size; - 按比例调整（如从 128MB → 512MB）：
SET GLOBAL innodb_buffer_pool_size = 536870912; - 确认生效且无报错后，**必须同步更新配置文件**，否则容器重启后还原
- 对
max_connections类变量，还需检查 OS 层限制：cat /proc/$(pidof mysqld)/limits | grep "Max open files"
最易忽略的一点：Docker 容器内 MySQL 的 pid-file 和 socket 路径若与宿主机冲突，会导致 SET GLOBAL 成功但后续连接失败——务必用 SHOW VARIABLES LIKE 'socket'; 核对实际路径是否在容器内可访问。
