MySQL权限最小化需为每个服务/实例单独建账号并授最小必要权限，禁用root应用连接；DBA账号离线保管、禁远程登录；8.0角色须隔离环境、显式激活；网络层须绑定内网IP、强制TLS、限制连接数。
MySQL账号权限最小化原则怎么落地
生产环境里，root账号绝不能用于应用连接，这是底线。真正该做的是为每个服务、每个模块甚至每个部署实例单独建账号，并只授予它**刚好够用**的权限。
常见错误是给应用账号 GRANT ALL PRIVILEGES ON *.*，结果一个SQL注入就能拖走全库；或者用 SELECT 权限连库，却忘了加 WITH GRANT OPTION 会导致权限被二次扩散。
- 只授权具体数据库：
GRANT SELECT, INSERT ON myapp_prod.* TO 'myapp_rw'@'10.20.30.%' - 敏感表单独限制：对
user_password表只允许UPDATE（由内部服务调用），禁止SELECT - 避免通配符主机：
'user'@'%'比'user'@'10.20.30.%'危险得多，DNS反查还可能绕过 - 用
REVOKE显式收回权限，别依赖“没给就是没有”——MySQL默认不启用sql_mode=STRICT_TRANS_TABLES时，部分越权操作可能静默失败
如何安全地管理高权限账号（如DBA账号）
DBA账号不是用来天天登录敲命令的，而是应急兜底用的。它的密码必须离线保管、定期轮换，且不能出现在任何配置文件或脚本中。
真实踩坑场景：运维把 admin 账号写进 Ansible 变量文件，Git 提交后全员可读；或者用 mysql -u root -p 在 shell 历史里留下明文密码。
- 高权限账号禁用远程登录：
CREATE USER 'dba_backdoor'@'localhost' IDENTIFIED BY 'xxx'; - 用
sudo+mysql_config_editor管理本地凭据，避免命令行暴露：mysql_config_editor set --login-path=dba --user=dba_backdoor --password - 开启
general_log会记录所有 SQL（含密码），生产必须关：SET GLOBAL general_log = OFF; - 审计日志建议用
audit_log插件而非慢日志替代，它能捕获DROP DATABASE、GRANT等高危操作
MySQL 8.0 的角色（ROLE）机制怎么用才不翻车
角色不是“语法糖”，它是批量授权和动态切换权限的关键。但直接 CREATE ROLE 后不绑定用户、不设密码策略，反而会放大风险。
典型问题：给开发建了 dev_role，又顺手 GRANT dev_role TO 'prod_app'@'%' —— 应用账号突然拥有了开发环境权限，且难以追溯。
- 角色本身不带密码，只管权限集合；必须用
SET DEFAULT ROLE或SET ROLE显式激活 - 禁止跨环境复用角色名：
prod_reader和staging_reader必须分离，哪怕权限内容一样 - 角色权限变更后，已登录用户不会自动刷新，需重新
SET ROLE或重连 —— 这点常被忽略，导致“改了权限但没生效”的误判 - MySQL 8.0.16+ 支持
ROLE_ADMIN权限控制谁可以GRANT ROLE，别让普通 DBA 能随意分配角色
从连接层堵住权限滥用漏洞
再细的权限划分，也挡不住一个开着 skip-grant-tables 启动的实例，或一个暴露在公网的 3306 端口。
很多团队花大力气设计权限体系，却忘了防火墙规则没配、MySQL 绑定地址还是 0.0.0.0、TLS 也没开 —— 权限再严，流量一抓全是明文账号密码。
- 确认
bind_address是内网IP，不是0.0.0.0或*；skip-networking只在本地调试时临时启用 - 强制 TLS：在
my.cnf加require_secure_transport = ON，并验证客户端是否真用了 SSL：SHOW STATUS LIKE 'Ssl_cipher'; - 连接数限制防爆破：
CREATE USER 'app'@'%' WITH MAX_CONNECTIONS_PER_HOUR 1000; -
wait_timeout和interactive_timeout设低些（比如 300 秒），减少空闲连接被劫持窗口
权限体系真正的复杂点不在 SQL 授权语句本身，而在于它必须和网络隔离、认证方式、审计链路、密钥生命周期全部咬合。漏掉任意一环，前面所有 GRANT 都可能归零。
