“using password: NO”表明命令未传递密码参数，而非密码错误；常见原因包括遗漏-p、--password=后无值、脚本中密码变量为空，正确做法是使用mysqldump -u root -p交互输入密码。
mysqldump报1045：using password: NO 是什么问题
这说明命令根本没传密码，不是密码错，是压根没给。mysql服务端看到空密码尝试，直接拒绝。
常见触发场景：
-
mysqldump -u root --all-databases—— 完全漏掉-p -
mysqldump -u root -p --all-databases写成-p=或--password=后面没跟值 - 脚本里用变量拼接，但变量为空或未导出
正确做法只有一种：mysqldump -u root -p --all-databases > backup.sql，回车后交互输入密码。别图省事硬编码，历史记录里全是明文密码。
mysqldump报1045：using password: YES 但密码没错？
密码确实对，但还是被拒，大概率是 host 或 plugin 不匹配。
先用命令行验证基础凭证：mysql -u root -p，输同样密码。能进 → 问题不在密码本身；进不去 → 才要改密。
如果命令行能进，但 mysqldump 报错，重点查这两项：
- 执行
SELECT user, host, plugin FROM mysql.user WHERE user = 'root';，看返回的host是localhost还是127.0.0.1—— 二者不等价，mysqldump默认走 TCP（即127.0.0.1），而localhost走 socket - 如果
plugin是caching_sha2_password，旧版 MySQL 客户端（包括部分mysqldump二进制）不支持，必须切回mysql_native_password
修复示例：ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'yourpass'; FLUSH PRIVILEGES;
密码含特殊字符导致 mysqldump 1045
Shell 解析会吃掉 !、$、? 等符号，导致传给 MySQL 的密码和实际不符。
比如 mysqldump -u root -pP@ssw0rd! ... 中的 ! 会被 Bash 当作历史展开符处理，最终传过去的是残缺密码。
安全且可靠的解法只有两个：
- 用
-p交互式输入（推荐） - 把凭证写进
~/.my.cnf，设好权限chmod 600 ~/.my.cnf，内容示例：
[client] user=root password=P@ssw0rd!
别用单引号/双引号包裹密码字段，.my.cnf 不认引号语法。
备份脚本里固定写死密码还报1045？检查 skip-grant-tables 残留
曾经用 skip-grant-tables 改过密的人最容易栽这儿：改完忘了删配置，MySQL 启动时跳过权限校验，所有连接都变成“凭空认证成功”，但 mysqldump 这类工具反而因缺失认证上下文而失败。
立刻检查：
grep skip-grant-tables /etc/my.cnf /etc/mysql/my.cnf /etc/my.ini 2>/dev/null-
systemctl show mysqld | grep MYSQLD_OPTS（Linux）或服务属性里启动参数（Windows）
只要发现任何地方有 skip-grant-tables，删掉、重启 MySQL 服务。这个开关不是“临时应急小技巧”，而是彻底绕过权限体系的危险模式，不该长期开着。
真正麻烦的从来不是密码本身，而是你改完密码后，没同步更新 host、plugin、skip-grant-tables 这三处隐性依赖 —— 它们不动声色地让 1045 反复出现。
