mysqldump报ERROR 1045主因是备份用户缺失SELECT、LOCK TABLES、SHOW VIEW、TRIGGER等最小必要权限，非密码或用户名错误；需用root执行SHOW GRANTS确认权限现状，再精准授权并FLUSH PRIVILEGES生效。
mysqldump报ERROR 1045：用户没被授予SELECT或LOCK TABLES权限
不是密码错了，也不是输错用户名——是账号压根没被授权执行备份操作所需的最小权限集。mysqldump默认会尝试加锁表、读取视图定义、查触发器元数据，缺一不可。
用root登录后执行：SHOW GRANTS FOR 'backup_user'@'localhost';，常见结果是只看到USAGE或仅有SELECT。必须补全以下权限：
-
SELECT（读所有表数据） -
LOCK TABLES（保证导出一致性） -
SHOW VIEW（若库中含视图，否则dump会中断） -
TRIGGER（若表有触发器）
执行授权后，必须运行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 ，但<code>app_db根本不存在，或该用户对app_db没有CREATE和INSERT权限，就会直接报错。
分两步解决：
- 先用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权限，也会失败。此时应手动删掉或注释掉这些行，只保留CREATE TABLE和INSERT部分。
备份文件属主为root，mysql用户无法读取
Linux下用sudo mysqldump生成的文件，属主常是root:root，但后续由www-data或mysql用户执行还原时，系统拒绝读取，报Permission denied。
别用chmod 777，改用更安全的属主调整：
- 查MySQL实际运行用户：
ps aux | grep mysql | grep -v grep，常见是mysql用户 - 改属主：
chown mysql:mysql backup.sql或chgrp mysql backup.sql && chmod 640 backup.sql - 容器环境要特别注意UID/GID映射；宿主机挂载进容器的文件，权限可能失效，优先在容器内执行
mysqldump
连接失败却显示Access denied：localhost走socket而非TCP
错误提示像Access denied for user 'backup_user'@'localhost'，但密码没错、权限也给了——问题往往出在连接方式上。localhost会强制走Unix socket，而socket路径可能不对，或用户host匹配的是'backup_user'@'%'而非'backup_user'@'localhost'。
绕过socket，强制走TCP：
- 备份时加
-h 127.0.0.1：mysqldump -h 127.0.0.1 -u backup_user -p app_db > backup.sql - 确认用户host字段是否匹配，必要时创建
'backup_user'@'127.0.0.1'并授权 - Docker多实例场景下，必须显式指定
-h和-P，不能依赖默认值
权限本身没问题，但连接没走到预期的用户记录上，是最容易被忽略的盲区。
