MySQL 8.0+ 必须用 ROLE 实现 DBA 权限隔离，通过 CREATE ROLE、GRANT 最小权限、SET DEFAULT ROLE 解耦用户与职责，并剥离 SUPER/PROCESS/REPLICATION CLIENT 等高危权限，辅以 CURRENT_ROLE() 校验确保操作上下文安全。
MySQL 8.0+ 如何用角色（ROLE）隔离 DBA 权限
MySQL 原生不支持“DBA 组”或“权限模板”，但 8.0+ 的 ROLE 是唯一靠谱的职责分离手段。不用角色，就只能靠手写 GRANT 拼凑，极易漏配、误授、难审计。
实操要点：
-
CREATE ROLE 'backup_admin';先建角色，别直接给用户授权 -
GRANT SELECT ON *.* TO 'backup_admin';只给最小必要权限，不要用GRANT ALL PRIVILEGES -
GRANT 'backup_admin' TO 'ops_user'@'%';用户与角色解耦，换人不改权限逻辑 - 角色默认不激活，用户登录后需执行
SET ROLE 'backup_admin';才生效（可设为默认：SET DEFAULT ROLE 'backup_admin' TO 'ops_user'@'%';）
哪些权限必须从 root/dba 账户中剥离出来
真正危险的是能绕过行级/列级控制、篡改元数据、导出全量数据的能力。以下权限一旦赋予普通管理员，基本等于交出数据库控制权：
-
SUPER：可 kill 线程、修改全局变量、绕过 binlog 限制 → 99% 场景不需要 -
PROCESS：能看到所有 SQL，含敏感查询和密码明文 → 备份/监控专用账号才需临时开启 -
REPLICATION CLIENT：能查主从状态，暴露架构细节 → 运维看板账号可授，但不应给应用 DBA -
SHUTDOWN和RELOAD：可停库、刷权限表 → 必须保留在 root 或自动化部署工具账号里
为什么不能靠 application user + dba user 双账号解决
双账号只是表层隔离，本质没解决权限复用和误操作问题。常见崩塌点：
- 开发连上
dba_user写了个DROP TABLE脚本，以为在测试库 —— 实际连的是生产实例（host 没配对） -
application_user需要加字段，DBA 顺手用ALTER TABLE ... ADD COLUMN，但忘了该表有JSON字段，触发隐式锁表 - 备份脚本用
mysqldump --all-databases，依赖SELECT+LOCK TABLES，但角色没显式授LOCK TABLES，半夜失败静默
核心矛盾在于：权限 ≠ 职责。角色是职责载体，账号只是入口。
audit_log 插件无法替代权限拆分
启用了 audit_log 只能事后追责，不能阻止误操作。它甚至会掩盖更严重的问题：
- 日志体积暴涨（尤其开启
QUERY级别），拖慢高并发实例 - 记录的是语句文本，不是执行上下文 —— 同一条
DELETE FROM users WHERE id = ?，参数不同，风险天壤之别 - 审计日志本身可被
SUPER权限关闭，如果 DBA 有该权限，等于审计形同虚设
真正可控的防线只有两条：角色粒度的权限预设 + 每次操作前的 CURRENT_ROLE() 校验（比如备份脚本开头加 SELECT CURRENT_ROLE(); 断言是否为 'backup_admin'）。
