日志中出现“Access denied for user 'root'@'localhost'”说明客户端已成功连接到mysqld进程，但身份认证失败，核心原因在于plugin类型（如auth_socket）与登录方式不匹配，或authentication_string为空、密码策略未满足、未执行FLUSH PRIVILEGES等认证环节配置问题。
这不是密码输错了，而是 MySQL 拒绝了认证流程本身——日志里出现这行，说明连接已抵达服务端，但验证环节失败了。
错误日志里真有这行，说明什么
日志中出现 Access denied for user 'root'@'localhost'，意味着客户端成功连上了 mysqld 进程，但认证阶段被拒绝。它不是网络不通、服务没起、socket 找不到这类底层问题，而是明确卡在“用户身份核验”这一步。
- 常见于首次安装后未处理临时密码，或改密后未刷新权限
- 也可能 root 用户的
plugin字段不是mysql_native_password或caching_sha2_password，而是auth_socket（尤其 Ubuntu/Debian 默认） - 若日志中同一时间还出现
Plugin 'auth_socket' is not loaded，说明插件缺失，但配置仍指向它，直接导致拒绝
查 plugin 和 authentication_string 是第一件事
别急着重置密码——先确认 root 用户当前用的是哪种认证方式：
- 停服务，加
--skip-grant-tables启动，再执行：SELECT User, Host, plugin, authentication_string FROM mysql.user WHERE User = 'root'; - 如果
plugin是auth_socket，且你没用 Unix socket 登录（比如用了-h 127.0.0.1），那必然失败——auth_socket只认系统用户，不走密码 - 如果
authentication_string为空但plugin是mysql_native_password，说明密码被清空但没刷新权限，需执行FLUSH PRIVILEGES;
临时密码没拿到，日志却为空？试试这几个路径
不是所有安装方式都把临时密码写进 /var/log/mysqld.log。优先按顺序试：
-
sudo grep 'temporary password' /var/log/mysql/error.log（Ubuntu/Debian 常用） -
sudo journalctl -u mysqld --since "1 hour ago" | grep 'temporary password'（systemd 系统） -
grep 'temporary password' /usr/local/var/mysql/*.err（macOS Homebrew） -
find /var/lib/mysql -name "*.err" -exec grep 'temporary password' {} \;（暴力定位）
看到 A temporary password is generated for root@localhost: xxxxxx 就对了——冒号后内容才是密码，复制时务必去掉末尾换行和空格。
ALTER USER 执行后仍报 ERROR 1820？密码策略在拦你
MySQL 5.7+ 和 8.0+ 默认启用密码强度校验，ALTER USER 成功不代表能立刻用新密码登录。触发 ERROR 1820 (HY000) 的典型原因：
- 新密码少于 8 位，或缺大写字母、小写字母、数字、特殊字符中的任意一类
- 用了
SET PASSWORD而非ALTER USER（5.7+ 已废弃前者） - 没指定 host：必须写全
'root'@'localhost'，不能只写'root' - 改完没执行
FLUSH PRIVILEGES;（虽然 ALTER USER 通常自动生效，但某些旧版本或插件组合下仍需手动刷）
开发环境想跳过验证，临时关插件：UNINSTALL PLUGIN validate_password;（注意：8.0+ 需先确认是否已加载，用 SHOW PLUGINS; 查）
真正麻烦的不是找不到密码，而是 plugin 和密码策略双重叠加——比如你用 auth_socket 却硬要输密码，或密码满足策略却 plugin 不匹配。这两层必须同时对齐，日志里的 Access denied 才会消失。
