MySQL权限需按环境严格隔离：用户账号和数据库名强制带环境后缀（如app_read_dev、dev_app_db），禁止跨环境复用账号，初始化SQL须显式指定host并FLUSH PRIVILEGES；Ansible中密码须用Vault加密分环境变量，避免明文；验证时用SELECT USER(), CURRENT_USER()确认实际匹配账号。
MySQL 权限怎么按环境隔离才不串？
不同环境（dev/staging/prod）用同一套权限逻辑，迟早出事。核心原则：权限必须和应用身份绑定，而不是靠人记“这个库 dev 能写，prod 只能读”。CREATE USER 和 GRANT 本身不带环境标签，得靠命名规范 + 配置分层来硬约束。
实操建议：
- 用户账号名强制带环境后缀，比如
app_read_dev、app_write_staging、app_api_prod—— 不是“建议”，是部署脚本里写死的规则 - 权限只授给具体数据库名，且库名也带环境前缀：
dev_app_db、staging_app_db、prod_app_db；绝不出现GRANT ... ON *.* - 禁止复用 root 或同名账号跨环境登录，哪怕只是临时查数据 —— 一次误操作就可能把 prod 表 truncate 到 dev 的备份里
Ansible 怎么安全注入 MySQL 用户密码？
明文写进 playbook 是最常见翻车点。mysql_user 模块支持 password 参数，但直接填字符串等于把密码塞进 Git 和日志。真正可行的是用 Ansible Vault 加密变量 + 动态查 vault 中对应环境的密码。
实操建议：
- 密码变量名按环境拆开：
mysql_user_app_dev_password、mysql_user_app_prod_password，每个都单独加密 -
mysql_user模块必须加state: present和priv: "db_name.*:SELECT,INSERT"，避免因 idempotence 问题漏授权 - 不要用
login_password连接 MySQL 管理节点 —— 改用 SSH key 登录跳板机，再用本地 socket 连localhost，省去网络传密过程
为什么 Docker Compose 启动的 MySQL 容器权限总不对？
容器启动时执行 docker-entrypoint.sh，它会运行 /docker-entrypoint-initdb.d/ 下的 SQL 文件，但这些脚本默认以 root 执行，建的用户没做 host 限定，结果 'app'@'%' 在 prod 环境也能连进来。
实操建议：
- 初始化 SQL 里所有
CREATE USER必须显式指定 host：CREATE USER 'app_dev'@'172.20.0.%'（对应 docker network 子网），绝不用'app_dev'@'%' - 用
command: ["mysqld", "--default-authentication-plugin=mysql_native_password"]，避免 MySQL 8 默认的 caching_sha2_password 导致旧应用连接失败 - initdb 脚本末尾加
FLUSH PRIVILEGES;—— 容器场景下有时不会自动刷，导致 grant 生效延迟
权限变更后如何验证没漏配？
光看 SHOW GRANTS FOR 'user'@'host' 不够。真实问题是：应用用的连接串里 host 是什么？DNS 解析后实际连到哪个 IP？MySQL 认的 host 是匹配 client IP 还是反向解析后的 hostname？这三者不一致，权限就白配。
实操建议：
- 在目标环境跑一句
SELECT USER(), CURRENT_USER();—— 前者是连接时声明的身份，后者才是 MySQL 实际匹配到的账号，两者不同说明 host 匹配失败 - 用应用相同配置的
mysql -h $HOST -u $USER -p手动连，别只信本地 socket 连接结果 - 上线前必查
SELECT user,host FROM mysql.user WHERE user LIKE 'app%';，确认 prod 相关账号的 host 字段不含通配符或开发网段
环境越复杂，越要靠命名、路径、SQL 脚本里的字面量来锁定行为，而不是依赖文档或口头约定。一旦开始用变量替换用户名或库名，就要同步检查所有地方是否做了环境感知 —— 少一个 if env == 'prod'，就多一分风险。
