error 1045或access denied主因是权限缺失而非密码或用户名错误；需确保账号具备select、lock tables、show view、trigger、reload等必要权限，mysql 8.0+推荐直接授予backup_admin角色并补充replication client（如需pitr），最后执行flush privileges生效。
mysqldump报ERROR 1045或Access denied，先确认是不是权限缺了
不是密码输错，也不是用户名打错——ERROR 1045和Access denied绝大多数情况是账号根本没被授够权限。mysqldump默认要读数据、锁表、查视图定义、读触发器，缺一不可。
-
SELECT：必须，否则连表都读不了 -
LOCK TABLES：保证导出一致性，MyISAM和InnoDB都依赖它 -
SHOW VIEW：库中只要有一个视图，没这个权限就会中断 -
TRIGGER：表带触发器时必需要，否则dump直接失败 -
RELOAD：用于FLUSH TABLES WITH READ LOCK，全库备份时关键 -
PROCESS和SHOW DATABASES：执行--all-databases时必需
用root登录后运行：SHOW GRANTS FOR 'backup_user'@'localhost';，如果只看到USAGE或只有SELECT，那就坐实了权限不足。
MySQL 8.0+用户别再零散授权，直接用BACKUP_ADMIN
MySQL 8.0起引入BACKUP_ADMIN角色，它打包了备份所需全部权限（含SELECT、LOCK TABLES、RELOAD、PROCESS等），比手写一堆GRANT更安全、更易维护。
- 授予权限只需一句：
GRANT BACKUP_ADMIN ON *.* TO 'backup_user'@'localhost'; - 若还需解析binlog位置（如做PITR），额外加：
GRANT REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost'; - 别忘了
FLUSH PRIVILEGES;，否则新权限不生效 - 远程备份注意host匹配：
'backup_user'@'%'≠'backup_user'@'localhost'，后者不接受TCP连接
恢复时报ERROR 1044，其实是CREATE/INSERT权限没给到位
还原命令mysql -u backup_user -p app_db 失败，常见原因是<code>app_db不存在，或该用户对app_db没有CREATE和INSERT权限——ERROR 1044就专报这种“无权建库/写表”。
- 先用root建库：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS app_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" - 再授表级权限：
GRANT CREATE, INSERT, DROP, ALTER, INDEX ON app_db.* TO 'backup_user'@'localhost'; - 如果
backup.sql开头有CREATE DATABASE或USE app_db，而用户又没CREATE DATABASE权限，就得手动删掉或注释掉这些行 - 导入时别在MySQL客户端里用
source，容易因没USE上下文报ERROR 1046；优先用管道：mysql -u backup_user -p app_db
权限改完还是不生效？检查三个隐性坑
执行了GRANT和FLUSH PRIVILEGES，但备份仍失败，问题常藏在这几个地方：
- 用户host不匹配：
'backup_user'@'127.0.0.1'和'backup_user'@'localhost'是两个不同账号，前者走TCP，后者走socket；强制走TCP就加-h 127.0.0.1 - SELinux或AppArmor拦截：
ls -Z /backup/path看上下文，或临时设为permissive模式验证是否是它拦的 - MySQL配置限制：某些环境启用了
skip-grant-tables或read_only=ON，会导致权限系统失效或拒绝写操作
真正卡住的地方，往往不是grant语句写得对不对，而是@'localhost'和@'%'这种细节、SELinux策略、或者read_only开关——它们不会报错，只会静默拒绝。
