备份专用账号最小权限为select+lock tables+reload+show view+trigger，需精确限定主机ip、禁用%通配、强制ssl加密连接，并显式撤销information_schema等敏感库访问权。
备份用户需要哪些权限，而不是“能干啥就给啥”
备份专用账号不是运维账号，不需要登录、执行命令或修改结构。它只负责把数据读出来——所以核心就是 SELECT + LOCK TABLES + RELOAD（用于 FLUSH TABLES WITH READ LOCK），外加 SHOW VIEW（否则视图导出为空）和 TRIGGER（否则 mysqldump 会跳过触发器）。漏掉 LOCK TABLES，--single-transaction 在非事务表上会失效；没 SHOW VIEW，mysqldump --all-databases 会报错 ERROR 1142 (42000): SELECT command denied。
为什么不能用 root 或 GRANT ALL PRIVILEGES ON *.*
root 账号一旦泄露，攻击者可直接 DROP DATABASE、CREATE USER、LOAD_FILE 甚至写入系统文件；而 GRANT ALL PRIVILEGES ON *.* 等价于授予 SHUTDOWN、FILE、SUPER 等高危权限，备份脚本若被注入或误配，后果不可逆。更隐蔽的风险是：某些备份工具（如 Percona XtraBackup）在非 root 模式下仍需 PROCESS 权限查看线程状态，但该权限也能看到其他用户的查询语句——应严格限制 host 为备份服务器 IP，而非 '%'。
创建时必须显式 REVOKE 并限定 host
MySQL 新建用户默认有 USAGE 权限，看似安全，但旧版本或权限缓存可能导致后续 GRANT 叠加出意外能力。标准操作链是：
-
CREATE USER 'backup_user'@'10.10.50.20' IDENTIFIED BY 'BkP@2026!';（host 必须精确到备份服务器 IP，不用'%'或网段） -
REVOKE ALL PRIVILEGES ON *.* FROM 'backup_user'@'10.10.50.20';（注意必须带ON *.*，否则无效） -
GRANT SELECT, LOCK TABLES, RELOAD, SHOW VIEW, TRIGGER ON *.* TO 'backup_user'@'10.10.50.20';（不授INSERT/UPDATE/DELETE，也不碰mysql系统库） -
REVOKE SELECT ON information_schema.* FROM 'backup_user'@'10.10.50.20';（防止通过information_schema.TABLES探测库表结构）
执行后用 SHOW GRANTS FOR 'backup_user'@'10.10.50.20'; 验证结果，确保没有残留 GRANT OPTION 或模糊 host 条目。
SSL 和密码策略不能跳过
备份流量走内网也不代表绝对安全——交换机镜像、宿主机抓包都可能截获明文凭据。必须强制 SSL：
- 创建时加
REQUIRE SSL：CREATE USER 'backup_user'@'10.10.50.20' IDENTIFIED BY 'BkP@2026!' REQUIRE SSL; - 确认服务端已配置有效证书（
ssl_ca、ssl_cert、ssl_key），且客户端连接时启用--ssl-mode=REQUIRED - MySQL 8.0+ 启用
validate_password插件，设为MEDIUM或更高，避免弱密码被爆破
真正容易被忽略的点是：备份脚本里硬编码密码时，别用 mysql -u backup_user -p'xxx' 这种方式——密码会出现在 ps aux 输出里。应改用 mysql_config_editor 存储加密凭据，或通过 --defaults-extra-file 指定权限为 600 的配置文件。
