mysqldump备份最小权限为SELECT、LOCK TABLES、SHOW VIEW、TRIGGER、EXECUTE（导出存储过程时），恢复需CREATE、INSERT、DROP、ALTER、INDEX等权限，DEFINER问题可通过--skip-definer解决。
直接给备份账号 ALL PRIVILEGES 或 SELECT ON *.* 是高危操作，真实场景中必须按备份工具类型精确匹配权限集——mysqldump 和 xtrabackup 所需权限完全不同，混用会导致备份失败或权限过度暴露。
mysqldump 备份账号必须包含 LOCK TABLES、SELECT、REPLICATION CLIENT
mysqldump 要保证一致性备份，不是只读就行。它需要显式加锁（LOCK TABLES），否则在并发写入时导出数据可能错乱；REPLICATION CLIENT 用于获取 binlog 位点，支撑后续增量恢复；SELECT 是基础，但必须限定到具体库，不能是 *.*。
-
LOCK TABLES权限不可省：即使只备份 InnoDB 表，--single-transaction模式下仍需该权限执行FLUSH TABLES WITH READ LOCK（某些旧版客户端或含 MyISAM 表时触发） - 必须显式授予
SHOW VIEW：否则导出视图会报ERROR 1142 (42000): SELECT command denied - 如果备份含触发器或事件，得额外加
TRIGGER和EVENT权限，否则 dump 文件里缺失定义 - 别给
PROCESS：它能让备份账号看到所有连接和 SQL 内容，属于监控类权限，和备份无关
xtrabackup 物理备份账号要避开 SUPER，优先用 RELOAD + LOCK TABLES
MySQL 8.0+ 已弃用 SUPER 对物理备份的支持，xtrabackup 2.4+ 默认用 RELOAD + LOCK TABLES 完成 FLUSH TABLES WITH READ LOCK，强行配 SUPER 反而增加攻击面。
-
RELOAD是关键：没有它，xtrabackup 无法刷新日志或释放锁，备份会卡在Waiting for log copying to finish -
CREATE TABLESPACE仅当备份启用--use-memory或涉及单独表空间文件（.ibd）时才需要，普通全量备份可不加 - 绝对禁止
INSERT/UPDATE/DROP：物理备份账号一旦获得写权限，可直接覆盖ibdata1或删库，比逻辑备份风险更高 - host 必须写死 IP，比如
'backup-srv'@'10.10.5.20'，不用'%'——xtrabackup 不走 DNS 解析，用主机名反而连不上
CREATE USER 必须指定 mysql_native_password 插件
MySQL 8.0 默认认证插件 caching_sha2_password 与多数备份工具不兼容，mysqldump 5.7 客户端、xtrabackup 2.4 甚至部分新版 mysqlpump 都会报 Authentication plugin 'caching_sha2_password' cannot be loaded，这不是密码错，是握手失败。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 建用户时必须显式写：
CREATE USER 'backup'@'10.10.5.20' IDENTIFIED WITH mysql_native_password BY 'StrongP@ss2026'; - 不要依赖
ALTER USER ... IDENTIFIED WITH ...补救：有些备份工具（如早期 mysqld_exporter 的 backup 模块）只在首次连接时协商插件，改完插件也连不上 - 确认备份服务出口 IP：容器内网地址（如
172.18.0.3）或云主机内网 IP（如阿里云192.168.0.100）才是真实 host，不是你本地机器的 IP
GRANT 后必须立刻 REVOKE information_schema.*
哪怕你只给了 SELECT ON `prod_db`.*，MySQL 默认仍允许该账号查 information_schema.TABLES、SCHEMATA 等元数据表——这会暴露所有库名、表结构、行数，对备份账号毫无必要，纯属信息泄露。
- 执行：
REVOKE SELECT ON information_schema.* FROM 'backup'@'10.10.5.20'; - 这条语句要求执行者本身有
SUPER或SYSTEM_VARIABLES_ADMIN权限，普通 DBA 账号可能没这权限，得提前检查 - performance_schema 可酌情保留部分表（如
events_statements_summary_by_digest），但user_privileges、role_edges这类含账号关系的表必须禁读 - 验证是否生效：
mysql -ubackup -p -h 10.10.5.20 -e "SELECT COUNT(*) FROM information_schema.TABLES;"应报ERROR 1142
最易被忽略的是权限作用域和 host 匹配的耦合性：一个 'backup'@'10.10.5.%' 账号，若备份服务实际从 10.10.6.15 出发，就完全连不上——此时看 SHOW GRANTS 全对，但连接层已失败，排查方向容易跑偏。
