困扰我许久的 MySQL 容器无限重启，竟被一行配置解决了！

背景：升级 MySQL 版本，容器却无限重启

前几天，我需要将一个老项目的 MySQL 5.7.22 数据库进行版本升级到5.7.44（小版本升级，docker compose方式启动）。习惯性地写了 docker-compose up -d，结果容器状态一直是 Restarting，根本没有启动成功。

查看日志，被刷屏了：

mysql_1  | chown: changing ownership of './sys/...': Read-only file system

mysql_1  | chown: changing ownership of './proc/...': Operation not permitted

mysql_1  | chown: cannot access './proc/46/task/46/fd/5': No such file or directory

MySQL 官方镜像的 entrypoint 脚本似乎在疯狂地试图修改 /sys 和 /proc 目录的权限，这当然会失败（容器内这些目录是只读的，即使加上 privileged: true 也不行）。

尝试过的“标准”解法都不完美

AI问了一圈，Deepseek给我推荐了几个解法：

1. 设置 MYSQL_RUN_CHOWN=false → 实测 MySQL 5.7 官方镜像根本不认这个变量。
2. 添加 privileged: true → 错误从 Read-only file system 变成 Operation not permitted，依然失败。
3. 自定义 entrypoint 脚本 → 虽然有效，但需要额外维护脚本，且绕过了官方的一些初始化逻辑。
4. 清空数据目录重新初始化 → 升级场景下数据丢失风险高，不现实。

我几乎要放弃了，直到我顺手把这个困扰丢给了Hermes （接的qwen3.6-plus）。

神来之笔：一个不起眼的配置 `working_dir`

通义千问给出了一个我从未想过的解法，也是我docker compose配置一直忽略的一个配置项：在 docker-compose.yml 的 MySQL 服务中，添加一行 working_dir: /var/lib/mysql。

完整的配置示例：

services:
  mysql:
    image: mysql:5.7
    working_dir: /var/lib/mysql   # 就是这一行
    volumes:
      - ./mysql_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: your_password
    # ... 其他配置

加上这行后，重启容器，日志瞬间干净了，MySQL 正常启动，数据也完好无损！

为什么这样就能解决问题？

简单来说，MySQL 官方 entrypoint 脚本在执行递归权限修复时，会使用相对路径 ./ 扫描。如果容器默认工作目录是根目录 /，那么 ./sys 就会指向宿主机的 /sys，从而引发错误。

而当我们将工作目录显式设置为 /var/lib/mysql 后，所有相对路径的操作都被限制在数据目录内，脚本再也不会“跑偏”去触碰 /sys 和 /proc 了。就这么简单，却极为有效。

注意事项

• working_dir 配置对 Docker 和 Docker Compose 都有效，在 docker run 中对应 -w /var/lib/mysql。
• 这个方案适用于 MySQL 5.7（我验证的版本），其他版本如果也有类似的 chown 遍历问题，不妨一试。
• 添加 working_dir 后，数据目录权限仍需正确（宿主目录属主应为 999:999），否则 MySQL 可能无法写入。