报ERROR 1044或1045主因是备份用户缺失SELECT、LOCK TABLES、SHOW VIEW三项关键权限，而非密码或用户名错误；需精确授予权限并执行FLUSH PRIVILEGES生效，且注意主机名、数据库作用域及文件属主匹配。
直接给结论：报 ERROR 1045 或 ERROR 1044 不是密码错了，也不是输错用户名，而是备份用户缺关键权限——SELECT、LOCK TABLES、SHOW VIEW 这三项必须齐备，少一个都可能中断备份。
mysqldump 报 ERROR 1045：用户没被授予 SELECT 或 LOCK TABLES 权限
这是最常见也最容易误判的错误。现象是输入密码后立刻报错，连表结构都读不出来。
- 先用 root 登录检查真实权限：
SHOW GRANTS FOR 'backup_user'@'localhost';，别猜，要看实际返回 - 如果只看到
USAGE或只有SELECT，说明权限不全 - 最小必要权限组合是：
SELECT（读数据）、LOCK TABLES（保证导出一致性）、SHOW VIEW（库中含视图时必加，否则 dump 中途退出） - 执行授权后，必须运行
FLUSH PRIVILEGES;，否则新权限不生效 - 不要用
GRANT ALL PRIVILEGES ON *.*，应限定到具体库，例如：GRANT SELECT, LOCK TABLES, SHOW VIEW ON `app_db`.* TO 'backup_user'@'localhost';
还原时报 ERROR 1044：目标库不存在或用户无 CREATE/INSERT 权限
命令写成 mysql -u backup_user -p app_db < backup.sql，但 app_db 根本不存在，或该用户对它没有 CREATE 和 INSERT 权限，就会直接失败。
- 还原前先建库：
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权限，就会卡住；此时应手动删掉或注释掉这些行，只保留CREATE TABLE和INSERT
备份脚本在 Linux 下因文件属主问题失败
常见于用 sudo mysqldump 生成的 backup.sql，属主是 root:root，而后续用普通用户（如 www-data 或 mysql）执行还原时被系统拒绝读取。
- 不要
chmod 777，改用：chown mysql:mysql backup.sql或chgrp mysql backup.sql && chmod 640 backup.sql - 确认 MySQL 实际运行用户：
ps aux | grep mysql | grep -v grep，常见是mysql，不是root - 如果备份由
cron触发，检查 crontab 是谁在跑：sudo crontab -u mysql -l，避免权限错位 - 容器环境要注意 UID/GID 映射不一致，优先在容器内生成备份，而非挂载外部文件再读
真正容易被忽略的是权限生效时机和作用域匹配：FLUSH PRIVILEGES 不执行=白授权；ON app_db.* 和 ON *.* 看似只差几个字符，但还原时指定库名就只认前者；另外，'backup_user'@'localhost' 和 'backup_user'@'127.0.0.1' 在 MySQL 里是两个不同账号，别搞混。
