必须挂载/var/lib/mysql，因为MySQL 8.0官方镜像硬编码该路径存储全部数据（表结构、redo log、系统库等），不挂载则数据写入容器临时文件系统，docker rm后彻底丢失；挂载是唯一不可妥协的硬性要求。
/var/lib/mysql 必须挂载到宿主机绝对路径，否则容器删除后数据彻底丢失。这是唯一不可妥协的硬性要求，其他所有配置都建立在此基础之上。
为什么必须挂载 /var/lib/mysql？
MySQL 8.0 官方镜像默认把全部数据（表结构、系统库、redo log、ibdata1、undo log）都写在 /var/lib/mysql 下。不挂载，就等于存在容器临时文件系统里，docker rm 后数据全丢，连恢复机会都没有。
- 常见错误现象：容器反复重启、卡在 Initializing database、日志报 Can't open the mysql.plugin table
- 不是挂错目录（比如挂到 /etc/mysql），就是挂了但宿主机目录为空父目录（如 /data）或混入非 MySQL 文件（干扰初始化）
用 bind mount 还是 named volume？
推荐 bind mount（-v /host/path:/var/lib/mysql），不是因为“更高级”，而是它更可控：
- 备份直接 rsync /host/path，不用查 docker volume inspect 找路径
- 排查问题时能直接 ls -l /host/path 看文件属主、大小、时间戳
- 迁移只需复制整个目录，不依赖 Docker daemon 状态
- 注意：宿主机目录必须提前创建，且不能是 root 创建后没改属主——MySQL 8.0 容器内以 UID 999 用户运行，所以要执行：sudo chown -R 999:999 /host/path
MYSQL_ROOT_PASSWORD 不生效？检查数据目录是否干净
环境变量只在首次初始化时起作用。如果宿主机挂载目录 /host/path 已存在旧数据（哪怕是上次中断留下的半初始化文件），MySQL 会跳过初始化流程，直接加载现有数据——此时 MYSQL_ROOT_PASSWORD、MYSQL_DATABASE 全部被忽略。
- 常见表现：连上去发现密码还是旧的、app_db 没自动建、日志里出现 mysqld: Can't open the mysql.plugin table
- 解决方法只有两个选项：
- 彻底清空：sudo rm -rf /host/path && sudo mkdir -p /host/path && sudo chown -R 999:999 /host/path
- 或确认该目录是同版本（如 mysql:8.0.33）生成的干净数据，否则可能因数据字典变更拒绝启动
配置文件挂哪里才生效？
MySQL 8.0 容器按顺序加载：/etc/mysql/my.cnf → /etc/mysql/conf.d/*.cnf → /etc/mysql/mysql.conf.d/*.cnf。
- 如果只挂一个配置文件，必须放 /etc/mysql/conf.d/custom.cnf（后缀 .cnf，路径必须是 conf.d），且内容开头必须有 [mysqld] 段
- 容易踩的坑：
- 把文件挂到 /etc/mysql/my.cnf 却覆盖了整个默认配置，导致缺失必要段（如 [client]）而启动失败
- 写了 MySQL 5.7 的参数（如 innodb_file_per_table=1），8.0 已默认开启，虽不报错但浪费配置项
- 忘了加 default_authentication_plugin=mysql_native_password，旧版客户端（Navicat、某些 JDBC 驱动）连不上
- 没设 default-time_zone='+8:00'，容器内时间与宿主机不一致，影响慢查询日志和定时事件
-v /host/path:/var/lib/mysql），不是因为“更高级”，而是它更可控：
- 备份直接 rsync /host/path，不用查 docker volume inspect 找路径
- 排查问题时能直接 ls -l /host/path 看文件属主、大小、时间戳
- 迁移只需复制整个目录，不依赖 Docker daemon 状态
- 注意：宿主机目录必须提前创建，且不能是 root 创建后没改属主——MySQL 8.0 容器内以 UID 999 用户运行，所以要执行：sudo chown -R 999:999 /host/path
MYSQL_ROOT_PASSWORD 不生效？检查数据目录是否干净
环境变量只在首次初始化时起作用。如果宿主机挂载目录 /host/path 已存在旧数据（哪怕是上次中断留下的半初始化文件），MySQL 会跳过初始化流程，直接加载现有数据——此时 MYSQL_ROOT_PASSWORD、MYSQL_DATABASE 全部被忽略。
- 常见表现：连上去发现密码还是旧的、app_db 没自动建、日志里出现 mysqld: Can't open the mysql.plugin table
- 解决方法只有两个选项：
- 彻底清空：sudo rm -rf /host/path && sudo mkdir -p /host/path && sudo chown -R 999:999 /host/path
- 或确认该目录是同版本（如 mysql:8.0.33）生成的干净数据，否则可能因数据字典变更拒绝启动
配置文件挂哪里才生效？
MySQL 8.0 容器按顺序加载：/etc/mysql/my.cnf → /etc/mysql/conf.d/*.cnf → /etc/mysql/mysql.conf.d/*.cnf。
- 如果只挂一个配置文件，必须放 /etc/mysql/conf.d/custom.cnf（后缀 .cnf，路径必须是 conf.d），且内容开头必须有 [mysqld] 段
- 容易踩的坑：
- 把文件挂到 /etc/mysql/my.cnf 却覆盖了整个默认配置，导致缺失必要段（如 [client]）而启动失败
- 写了 MySQL 5.7 的参数（如 innodb_file_per_table=1），8.0 已默认开启，虽不报错但浪费配置项
- 忘了加 default_authentication_plugin=mysql_native_password，旧版客户端（Navicat、某些 JDBC 驱动）连不上
- 没设 default-time_zone='+8:00'，容器内时间与宿主机不一致，影响慢查询日志和定时事件
/etc/mysql/my.cnf → /etc/mysql/conf.d/*.cnf → /etc/mysql/mysql.conf.d/*.cnf。
- 如果只挂一个配置文件，必须放 /etc/mysql/conf.d/custom.cnf（后缀 .cnf，路径必须是 conf.d），且内容开头必须有 [mysqld] 段
- 容易踩的坑：
- 把文件挂到 /etc/mysql/my.cnf 却覆盖了整个默认配置，导致缺失必要段（如 [client]）而启动失败
- 写了 MySQL 5.7 的参数（如 innodb_file_per_table=1），8.0 已默认开启，虽不报错但浪费配置项
- 忘了加 default_authentication_plugin=mysql_native_password，旧版客户端（Navicat、某些 JDBC 驱动）连不上
- 没设 default-time_zone='+8:00'，容器内时间与宿主机不一致，影响慢查询日志和定时事件
复杂点在于：挂载 /var/lib/mysql 是底线，但真正让服务可恢复、可维护，还得同步处理权限、初始化状态、配置生效逻辑——三者缺一不可。尤其注意，宿主机目录一旦有残留，MySQL 就不会重走初始化流程，这个行为没法绕过。
