ERROR 1044主因是备份用户缺失SELECT、LOCK TABLES、SHOW VIEW、TRIGGER等最小必要权限，非密码或用户名错误；需用root执行SHOW GRANTS确认权限现状，再精准授权并FLUSH PRIVILEGES生效。
mysqldump报ERROR 1044：不是密码错，是权限缺
直接结论：mysqldump 报 ERROR 1044: Access denied for user 'xxx'@'xxx' to database 'xxx' when using LOCK TABLES，90% 以上不是输错密码，也不是账号不存在，而是该用户根本没被授予备份所需的最小权限集。哪怕你能用这个账号执行 SELECT * FROM t1，mysqldump 仍会因查 information_schema、锁表、读视图或触发器元数据而失败。
验证方式很简单：用 root 登录后执行SHOW GRANTS FOR 'backup_user'@'localhost';
如果返回里只有 USAGE，或只含 SELECT，那就确认缺权限了。
必须补全的四类基础权限（按库粒度授予）
缺一不可，且不能用 GRANT ALL PRIVILEGES ON *.* 这种宽泛授权——既不安全，也常因系统库限制而静默失效。
-
SELECT：读取所有表数据（含information_schema中的元数据） -
LOCK TABLES：保证导出时表级一致性（除非你明确接受不一致风险） -
SHOW VIEW：若目标库含视图，否则mysqldump会在读视图定义时报错中断 -
TRIGGER：若表有触发器，否则 dump 会卡在触发器元数据查询阶段
实操命令示例（以 app_db 为例）：GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `app_db`.* TO 'backup_user'@'localhost';FLUSH PRIVILEGES;
⚠️ 注意：FLUSH PRIVILEGES 不可省——权限变更写入磁盘后，必须刷新内存缓存才生效。
为什么加了 --single-transaction 还报“you need PROCESS privilege”
这个错误明确指向 PROCESS 权限缺失。MySQL 8.0+ 和多数云 RDS 实例中，mysqldump 在初始化连接时默认调用 SHOW PROCESSLIST 或查 INFORMATION_SCHEMA.PROCESSLIST，用于判断是否支持事务一致性快照。
该权限是全局的，无法限定到单库：GRANT PROCESS ON *.* TO 'backup_user'@'localhost';FLUSH PRIVILEGES;
若环境禁止开放 PROCESS（如某些金融级 RDS），可用以下组合绕过，但需验证导出完整性：--skip-opt --no-tablespaces --skip-triggers --skip-routines
导出为空或只含 CREATE DATABASE？别急着加权限
文件大小几 KB、打开全是注释或只有 CREATE DATABASE 语句，大概率不是权限问题，而是连接上下文失效：
- 数据库名拼写错误或大小写不匹配（Linux 下
AppDB≠appdb） - 误用
localhost导致走 socket 连接，而账号只允许127.0.0.1（或反之）；加-h 127.0.0.1强制 TCP 可快速验证 - 命令漏写数据库名：
mysqldump -u user -p后没跟库名，就会默认尝试--all-databases，结果因无权访问mysql等系统库而中断
最易被忽略的一点：密码含 @、%、# 等 shell 特殊字符时，未用单引号包裹会导致密码被截断。例如：mysqldump -u admin -pQinxiXiRoot@2022% app_db → 错mysqldump -u admin -p'QinxiXiRoot@2022%' app_db → 对
