优先选'backup'@'localhost'：本地备份足够，更安全快速；若需远程备份则改用'backup'@'%'并限制源IP；禁止用'127.0.0.1'因其与localhost权限不互通。
必须用最小权限账号执行 mysqldump，不能用 root；否则一旦备份脚本或配置泄露，等于直接交出数据库最高控制权。
创建账号时 host 值选 localhost 还是 %？
优先选 'backup'@'localhost'：
- 本地备份（如 mysqldump -h127.0.0.1）完全够用
- 避免远程暴露账号密码（哪怕加了 SSL，也多一层风险）
- 若真需远程备份（如 DBS、DMS 等云服务拉取），再改用 'backup'@'%'，且务必配合防火墙限制源 IP
别写成 'backup'@'127.0.0.1' —— MySQL 认为它和 localhost 是两个不同 host，而 localhost 走 socket 连接，更安全、更快。
GRANT 语句里哪些权限缺一不可？
以下权限组合是 mysqldump 全库逻辑备份的底线，少一个都可能失败：
-
SELECT：读所有表数据（必选） -
LOCK TABLES：保证一致性快照（加--single-transaction时可降级为 InnoDB 表专用，但没它就无法锁 MyISAM 表） -
RELOAD：触发FLUSH TABLES WITH READ LOCK（尤其在无事务引擎或禁用--single-transaction时关键） -
PROCESS：查看当前线程，mysqldump用它判断是否能安全加锁 -
SHOW VIEW：导出视图定义（否则只导空 CREATE VIEW） -
TRIGGER和EVENT：若库含触发器或事件调度器，不加这两项，备份文件里就没有对应CREATE TRIGGER/CREATE EVENT语句
注意：REPLICATION CLIENT 只在你要用 --master-data 记录 binlog 位点时才需要；SUPER 或 BACKUP_ADMIN（MySQL 8.0+）完全没必要——那是物理备份或管理命令用的，逻辑备份用不到。
执行完 GRANT 后一定要 FLUSH PRIVILEGES 吗？
绝大多数情况下不需要：
- MySQL 5.7+ 中，
GRANT语句本身会自动刷新权限缓存 - 只有当你绕过
GRANT、直接 INSERT 到mysql.user表时，才必须手动FLUSH PRIVILEGES - 多此一举反而可能掩盖权限未生效的真实问题（比如 host 写错、大小写不匹配）
验证方式更可靠：用新账号登录后执行 SHOW GRANTS FOR CURRENT_USER();，看输出是否和你 GRANT 的一致。
密码强度与连接方式容易被忽略
即使权限最小化，弱密码仍是最大突破口：
- 密码至少 12 位，含大小写字母 + 数字 + 符号（如
ccr_test123456!） - 禁止明文写在
mysqldump命令里（如-p123456），会被ps aux看见；改用~/.my.cnf并设chmod 600 - 生产环境强制启用
require_secure_transport=ON，确保该账号只能走 TLS 连接
真正难的不是建账号，而是让这个账号在所有备份路径（定时任务、CI/CD、运维平台）里都以安全方式被调用——权限、密码、传输通道，三者缺一不可。
