答案是空用户''@'localhost'优先匹配导致认证失败，需删除该账号并刷新权限。mysql按user+host精确匹配，空用户不校验密码且优先于'root'@'localhost'，造成输对密码仍报access denied；查删空用户后执行flush privileges;即可恢复。
为什么改完密码还是连不上：root@localhost 被空用户挤掉了
MySQL 认证时会按 user + host 组合精确匹配，且存在「空用户名」（即 ''@'localhost'）这种特殊账号。它不校验密码，只要存在，就会在认证阶段优先于 'root'@'localhost' 匹配成功——结果你输对了 root 密码，却进了空用户会话，后续所有权限操作都失败。
常见现象包括：
- 执行
mysql -u root -p后直接进去了，但提示Access denied for user ''@'localhost' - 用新密码登录报错
Access denied for user 'root'@'localhost'，但mysql -u "" -h localhost却能进 - 重置密码后
FLUSH PRIVILEGES;没报错，但新密码仍无效
实操建议：
- 登录 MySQL 后立刻查：
SELECT user, host FROM mysql.user WHERE user = '' OR user IS NULL; - 确认存在空用户后，删掉它：
DROP USER ''@'localhost';（MySQL 5.7+）或DELETE FROM mysql.user WHERE user = '';（5.6 及更早），再FLUSH PRIVILEGES; - 别只盯着
'root'@'localhost'，顺手检查'root'@'%'和'root'@'127.0.0.1'是否也存在——它们是独立账号，权限可能不一致
host 匹配顺序决定谁先上：localhost ≠ 127.0.0.1
MySQL 对 host 字段做排序匹配，规则是「越具体越靠前」。'root'@'localhost' 和 'root'@'127.0.0.1' 不是同一个账号，也不共享密码。本地连接默认走 Unix socket，匹配的是 localhost；加 -h 127.0.0.1 强制走 TCP，就去找 'root'@'127.0.0.1' ——如果这个账号没设密码或被删了，就会报错。
验证方式：
-
mysql -u root -p→ 走 socket，匹配'root'@'localhost' -
mysql -h 127.0.0.1 -u root -p→ 走 TCP，匹配'root'@'127.0.0.1' -
mysql -S /tmp/mysql.sock -u root -p→ 显式指定 socket，强制走'root'@'localhost'
容易踩的坑：
- 宝塔面板默认用 TCP 连接，所以即使你只配置了
'root'@'localhost'，面板也会连不上 - 某些 Docker 镜像或云数据库默认禁用
localhost，只留'root'@'%'，但又限制了远程登录（安全组/白名单） - MySQL 8.0+ 默认创建
'root'@'localhost'，但不会自动创建'root'@'127.0.0.1'，得手动补
ALTER USER 后密码没生效？先看认证插件是否兼容
MySQL 8.0+ 默认用 caching_sha2_password 插件，老客户端（如 MySQL 5.7 客户端、某些 Python 驱动、宝塔旧版）不支持，会静默拒绝连接，报错仍是 Access denied，但实际不是密码错，而是握手失败。
查当前用户插件：
-
SHOW CREATE USER 'root'@'localhost';→ 看IDENTIFIED WITH后面是什么 - 如果是
mysql_native_password，说明已降级；如果是caching_sha2_password，而你用的是旧客户端，就得改插件
临时兼容方案（不推荐长期用）：
- 改回老插件：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '新密码'; - 或启动时加参数：
mysqld --default-authentication-plugin=mysql_native_password（需改配置并重启）
注意：SET PASSWORD 在 8.0+ 已不推荐，且不会自动切换插件；只有 ALTER USER ... IDENTIFIED WITH 才能同时更新插件和密码。
跳过权限表重置密码后连不上：FLUSH PRIVILEGES 被忽略了
用 --skip-grant-tables 启动后，MySQL 不加载权限表，此时任何 SQL 修改（比如 UPDATE mysql.user）都不会被校验，但也不会自动写入磁盘——必须显式执行 FLUSH PRIVILEGES; 才真正刷新内存中的权限缓存。否则重启服务后，修改就丢了。
关键步骤顺序不能错：
- 停服务 →
mysqld_safe --skip-grant-tables &→mysql -u root（不加-p） - 进库后先
FLUSH PRIVILEGES;，再执行ALTER USER 'root'@'localhost' IDENTIFIED BY 'xxx'; - 退出，正常重启 mysqld（去掉
--skip-grant-tables）
最容易被忽略的一点：MySQL 8.0+ 的 authentication_string 字段是哈希值，直接 UPDATE 字段再 FLUSH 是无效的，必须用 ALTER USER 或 SET PASSWORD（后者仅限 5.7）。
