mysqldump报Access denied主因是权限缺失，需授予SELECT、LOCK TABLES、SHOW VIEW、TRIGGER四类最小权限；若用--single-transaction或--all-databases，还须全局授予PROCESS权限；同时需检查文件系统写入权限和socket连接问题。
直接结论：新装 MySQL 环境下 mysqldump 报 Access denied，90% 不是密码错，而是账号压根没被授过备份所需权限；剩下 10% 是文件系统写入权限或 socket 连接权限问题。
mysqldump Access denied 是缺哪些权限？
MySQL 用户必须显式拥有以下权限（按需组合），仅能登录或查表 ≠ 能导出：
-
SELECT：读取所有待导出表的数据 -
LOCK TABLES：保证 MyISAM 表一致性（InnoDB 下--single-transaction可绕过，但默认仍会尝试） -
SHOW VIEW：库中存在视图时必需，否则跳过或报错 -
TRIGGER：表含触发器时必需，否则导出 SQL 缺失触发器定义 -
PROCESS（全局）：启用--single-transaction或--all-databases时，mysqldump 会查INFORMATION_SCHEMA.PROCESSLIST，缺此权限就报 “you need the PROCESS privilege”
不要用 GRANT ALL PRIVILEGES ON *.* —— 最小权限原则更安全。例如只导 app_db：
GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `app_db`.* TO 'backup_user'@'localhost'; GRANT PROCESS ON *.* TO 'backup_user'@'localhost'; -- 注意：PROCESS 必须全局授予 FLUSH PRIVILEGES;
为什么 root 能登录却跑不了 mysqldump？
常见于新装环境默认只创建了 root@localhost，但该账号可能通过 socket 认证（如 auth_socket 插件），而 mysqldump 默认走 TCP 或不兼容认证方式，导致连接失败或权限降级。
验证方式：
- 执行
mysql -u root -p -e "SELECT USER(), CURRENT_USER();"，若返回root@localhost和root@localhost，说明认证正常；若后者是''@'localhost'，说明认证失败、权限为空 - 检查插件：
SELECT User, Host, plugin FROM mysql.user WHERE User = 'root';，若 plugin 是auth_socket，需改用mysql_native_password或创建专用备份账号
稳妥做法：新建账号并显式授权，而非强依赖 root：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_pass'; GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `app_db`.* TO 'backup_user'@'localhost'; GRANT PROCESS ON *.* TO 'backup_user'@'localhost'; FLUSH PRIVILEGES;
导出文件写不进目录？检查三处文件权限
即使数据库权限全了，mysqldump -u user -p app_db > /backup/app.sql 仍可能静默失败或报错“Permission denied”，原因在操作系统层：
- 目标目录不存在或不可写：
ls -ld /backup，确认执行命令的 Linux 用户对该路径有w权限 - 若用
sudo mysqldump ...，注意重定向>是 shell 执行的，属当前用户而非 root —— 应改用sudo sh -c 'mysqldump ... > /backup/app.sql' - SELinux 启用时（如 CentOS/RHEL），即使目录权限正确，也可能拦截写入：
ausearch -m avc -ts recent | grep mysqldump查日志，临时测试可setenforce 0
推荐做法：备份目录归执行用户所有，且不用 /var/lib/mysql 等敏感路径，例如：
mkdir -p ~/backups chmod 700 ~/backups mysqldump -u backup_user -p app_db > ~/backups/app_$(date +%F).sql
连接失败但没报 Access denied？试试加 -h 127.0.0.1
新装环境常默认配置为 socket 连接，而某些发行版或 Docker 场景下 socket 文件路径异常（如 /var/run/mysqld/mysqld.sock 不存在或权限不对），mysqldump 就会卡住或报错“Can't connect to local MySQL server”。
强制走 TCP 可绕过 socket 问题：
- 加
-h 127.0.0.1（不是-h localhost，后者仍可能走 socket） - 确保
bind-address在/etc/my.cnf中未被注释或设为127.0.0.1 - 检查
skip-networking是否开启，若是，需注释掉并重启 mysqld
验证是否生效：mysql -h 127.0.0.1 -u backup_user -p -e "SELECT 1;" 成功，再试 mysqldump -h 127.0.0.1 ...。
新装环境最易忽略的是 PROCESS 权限和 socket 连接路径——前者导致 --single-transaction 直接失败，后者让整个命令卡在连接阶段，连错误信息都不完整。
