MySQL初始化密码未修改导致1045_日志分析定位_密码重置与权限修复_实用教程
MySQL的1045错误分为using password: NO和using password: YES两种情况，处理方式不同。NO表示客户端没有发送密码，YES表示发送了密码但不正确。遇到NO类型的错误，重点检查客户端为什么没有发送密码，而不是去重置MySQL密码。很多人一看到1045就重置密码，结果问题依然存在，因为根本原因是客户端配置问题。本文详细讲解NO类型1045错误的排查和解决。
原因一：命令行缺少-p参数。直接输入mysql或mysql -u root，没有加-p参数，客户端不会提示输入密码，也不会发送密码，导致using password: NO。正确命令是mysql -u root -p，-p参数告诉客户端需要密码验证，执行后会提示Enter password:，输入密码后登录。如果想在命令行直接输入密码：mysql -u root -p密码，注意-p和密码之间没有空格，有空格的话密码会被当作数据库名。也可以使用--password=密码的长格式。
原因四：localhost和127.0.0.1的区别。使用mysql -u root -p连接localhost时，MySQL客户端默认使用unix socket（Linux）或命名管道（Windows）连接，而不是TCP连接。socket连接时，MySQL的用户认证可能与TCP连接不同。如果'root'@'localhost'用户不存在或密码不同，而'root'@'127.0.0.1'存在，使用localhost连接会失败。可以尝试使用TCP连接：mysql -u root -p -h 127.0.0.1 --protocol=tcp，强制使用TCP协议。检查mysql.user表中root用户的host字段，确认localhost和127.0.0.1都有对应用户且密码一致。
原因五：MySQL 8.0的认证插件差异。MySQL 8.0默认使用caching_sha2_password认证插件，旧版本客户端（如MySQL 5.7的客户端）不支持这个插件，连接时可能出现异常，包括using password: NO的错误。使用MySQL 8.0的客户端连接8.0服务器，或者修改用户认证插件为mysql_native_password：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '密码'; FLUSH PRIVILEGES;。同时确认客户端版本与服务器版本兼容，版本差异过大可能导致各种连接问题。
预防连接问题的最佳实践：使用正确的命令行参数，养成mysql -u用户名 -p的习惯；客户端和服务器版本保持一致或兼容；统一使用localhost或127.0.0.1，了解两者区别；配置文件中password值正确，不要留空；不使用MYSQL_PWD环境变量；多实例环境指定正确的socket和端口；MySQL 8.0根据客户端情况选择合适的认证插件；定期测试数据库连接，避免程序部署时才发现问题；记录数据库连接信息，使用密码管理工具保存；为不同应用创建独立数据库用户，避免都使用root。
运维经验：遇到using password: NO的1045错误，一开始以为是密码问题，重置了好几次密码都没用。后来用--no-defaults参数测试，发现是my.cnf中[client]段的password值为空导致的。删除空password配置后问题解决。遇到NO类型的1045，先检查客户端配置，不要急着重置密码。
安全提示：重置MySQL密码时使用--skip-networking防止远程连接，操作完成后立即移除skip-grant-tables并正常启动。不要在命令行直接输入密码（mysql -p密码），因为密码会记录在历史记录中，推荐使用-p交互输入。生产环境使用独立数据库用户，不要用root连接应用。
更新时间：2026-08-26 23:37:18