MySQL容器启动时仅靠MYSQL_USER环境变量无法实现可控权限管理，因其仅在空数据目录时创建用户并授予单库ALL PRIVILEGES，不支持角色、多库、细粒度权限或主机限制；必须通过/docke-entrypoint-initdb.d/下的幂等SQL脚本显式创建用户、角色、授权并设置默认角色，同时注意认证插件兼容性与文件编码、权限等细节。
MySQL 容器启动时不会自动创建业务用户，MYSQL_USER 和 MYSQL_PASSWORD 环境变量仅在数据库为空时生效，且只对 MYSQL_DATABASE 赋予 ALL PRIVILEGES —— 这不是“默认权限”，而是初始化脚本的有限行为；真要实现可控、可复现的权限分级，必须自己写 /docker-entrypoint-initdb.d/ 下的 SQL 或 Shell 脚本。
为什么不能只靠 MYSQL_USER 环境变量
官方 MySQL 镜像（如 mysql:8.0）在首次启动时会检查 /var/lib/mysql 是否为空。若为空，它才执行内置初始化逻辑：
-
MYSQL_ROOT_PASSWORD必须设置，否则容器启动失败 -
MYSQL_DATABASE会触发创建同名数据库 -
MYSQL_USER+MYSQL_PASSWORD会创建用户，并授予ALL PRIVILEGES ON $MYSQL_DATABASE.*—— 仅此而已，不支持角色、不支持多库、不支持细粒度权限（如只读） - 一旦数据目录已存在（比如挂载了已有 volume），整个初始化流程跳过，环境变量完全失效
这意味着：用 MYSQL_USER 创建的用户无法继承角色，不能限制主机范围（固定为 '%'），也无法撤销或调整权限——它是一次性、不可维护的。
如何编写可靠的 docker-entrypoint-initdb.d 初始化脚本
把权限逻辑从环境变量解耦出来，统一用 SQL 脚本控制，是生产环境唯一可依赖的方式。脚本需满足三个条件：可重复执行（幂等）、兼容 MySQL 8.0+ 认证插件、避免 FLUSH PRIVILEGES 误用。
- 文件必须放在
/docker-entrypoint-initdb.d/目录下，后缀为.sql或.sh；镜像会按字母序执行 - SQL 脚本中不要用
root@localhost登录判断，因为初始化阶段 root 密码来自MYSQL_ROOT_PASSWORD，且连接上下文已预置 - 创建用户时显式指定认证插件，MySQL 8.0 默认是
caching_sha2_password，但旧客户端可能不支持，可改用：CREATE USER 'app_ro'@'%' IDENTIFIED WITH mysql_native_password BY 'pass123'; - 角色必须在用户前创建，且
GRANT后需配SET DEFAULT ROLE才能让用户实际生效权限 - 避免在脚本里写
FLUSH PRIVILEGES：用GRANT/CREATE ROLE等 DCL 语句操作权限系统，MySQL 自动刷新缓存；只有直接 UPDATEmysql.user表才需要它
示例 /docker-entrypoint-initdb.d/setup-perms.sql：
CREATE ROLE IF NOT EXISTS 'app_reader', 'app_writer'; GRANT SELECT ON myapp.* TO 'app_reader'; GRANT SELECT, INSERT, UPDATE ON myapp.* TO 'app_writer'; <p>CREATE USER IF NOT EXISTS 'ro_user'@'%' IDENTIFIED WITH mysql_native_password BY 'ro_pass'; CREATE USER IF NOT EXISTS 'rw_user'@'%' IDENTIFIED WITH mysql_native_password BY 'rw_pass';</p><p>GRANT 'app_reader' TO 'ro_user'@'%'; GRANT 'app_writer' TO 'rw_user'@'%'; SET DEFAULT ROLE ALL TO 'ro_user'@'%', 'rw_user'@'%';
挂载脚本时容易踩的权限和路径坑
Docker 挂载 SQL 脚本到 /docker-entrypoint-initdb.d/ 是常见做法，但以下问题高频导致初始化静默失败：
- 宿主机脚本换行符为 CRLF（Windows），容器内执行时报错
unknown command 'n'：保存为 LF 格式（VS Code 右下角切换） - 挂载路径写成
./init.sql:/docker-entrypoint-initdb.d/init.sql，但文件实际在子目录，路径错误导致脚本不被发现 - 脚本有中文注释或 UTF-8 BOM 头，MySQL 解析失败，报错类似
Unknown character set: ''：用xxd init.sql | head检查开头是否含ef bb bf，有则去除 BOM - 使用
docker run -v挂载时，宿主机文件权限为 600，容器内 MySQL 进程（uid=999）无读取权限：加:ro,z或改权限为 644 - 脚本中用了
USE mydb;，但mydb尚未创建：确保先CREATE DATABASE IF NOT EXISTS mydb;，或用mydb.table全限定名
真正可靠的初始化，不靠环境变量猜意图，也不靠手动进容器跑命令；它是一份可 Git 版本管理、可测试、可注入 CI 流程的 SQL 文件。最常被忽略的是角色默认激活（SET DEFAULT ROLE）和认证插件兼容性——没这两条，用户连上去也是 “Access denied” 或 “Client does not support authentication protocol”。
