优先查错误日志获取临时密码：Linux执行sudo grep 'temporary password' /var/log/mysqld.log，macOS执行grep 'temporary password' /usr/local/var/mysql/*.err，Windows在C:\ProgramData\MySQL\MySQL Server 8.0\Data*.err中搜索；查到即试登录，成功则终止流程，否则启用--init-file或--skip-grant-tables（Windows需加--shared-memory）方式重置。
生产环境中重置 MySQL 8.0 的 root 密码，不能靠猜、不能删日志、更不能重装——必须在不丢失数据、不中断业务（停机窗口可控）、且满足审计合规的前提下完成。核心原则只有一条：优先从错误日志提取初始密码；失效时才走 --skip-grant-tables 或 --init-file 路径，且每一步都要可逆、可验证、留痕。
怎么快速确认是否还能用初始密码登录？
MySQL 8.0 安装或初始化后生成的临时密码，只写进错误日志一次，后续任何操作都不会覆盖它。只要日志文件没被 logrotate 彻底删除或手动清空，就值得先查。
- Linux：运行
sudo grep 'temporary password' /var/log/mysqld.log（常见路径还有/var/log/mysql/error.log） - macOS（Homebrew）：
grep 'temporary password' /usr/local/var/mysql/*.err - Windows：打开隐藏目录
C:\ProgramData\MySQL\MySQL Server 8.0\Data\*.err，用记事本或 PowerShell 搜索temporary password - 如果用
mysqld --initialize手动初始化过，密码一定出现在该命令的 stderr 输出里，或同级目录下的.err文件中
查到后立刻试： mysql -u root -p + 粘贴密码。成功即止，无需后续操作。失败再往下走。
为什么 --skip-grant-tables 在生产环境容易失败？
直接跑 mysqld --skip-grant-tables 在生产环境大概率起不来，不是配置错，而是它和现代 MySQL 的安全机制天然冲突。
- Windows 必须加
--shared-memory（推荐）或--enable-named-pipe，否则报错TCP/IP, --shared-memory, or --named-pipe should be configured - Linux/macOS 若启用了
caching_sha2_password插件或binlog_checksum=ON，可能崩溃；可临时加--disable-plugin=caching_sha2_password或在配置里设binlog_checksum=NONE - 路径错误是高频坑：
mysqld默认找C:\Program Files\...\data，但真实数据目录在C:\ProgramData\...\Data；必须显式指定--datadir="C:\ProgramData\MySQL\MySQL Server 8.0\Data" -
--skip-grant-tables启动后，mysql -u root能进，但后续所有 SQL 都依赖你手动执行USE mysql;和FLUSH PRIVILEGES;，漏一步就白忙
--init-file 方式为什么更适合生产环境？
它不绕过权限系统，而是让 mysqld 在启动时“自动执行一条 SQL”，全程静默、原子、可审计，且不需要额外开终端、不卡住进程。
- 新建一个纯文本文件，比如
/tmp/reset-root.sql（Linux/macOS）或C:\reset.sql（Windows），内容只有一行：ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass123'; - 确保该 SQL 文件权限严格（如
chmod 600 /tmp/reset-root.sql），避免泄露密码明文 - 停服务后，用完整路径启动：
mysqld --init-file=/tmp/reset-root.sql --datadir=/var/lib/mysql（Linux）或mysqld --init-file=C:\reset.sql --defaults-file="C:\ProgramData\MySQL\MySQL Server 8.0\my.ini"（Windows） - mysqld 启动成功后会自动退出（非卡住），此时删掉
--init-file参数，按正常方式重启服务即可 - 注意：该方式只改
'root'@'localhost'，若需支持远程登录，得额外补一句ALTER USER 'root'@'%' IDENTIFIED BY 'MyNewPass123';
改完密码为什么还是连不上？三个最常忽略的点
不是密码没生效，而是连接时匹配的 host 或插件不对，现象是报 Access denied 却死活找不到原因。
- 用
mysql -h 127.0.0.1 -u root -p连，实际匹配的是'root'@'127.0.0.1'，不是'root'@'localhost'；必须同步改这条记录，或统一用-h localhost - MySQL 8.0 默认认证插件是
caching_sha2_password，但某些老客户端（如旧版 MySQL Workbench、PHP mysqli）不支持；可临时切回：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'MyNewPass123'; - 密码策略强制要求 8 位+大小写+数字+特殊字符，设
'123'会报ERROR 1819 (HY000)；临时放宽策略要改两个变量：SET GLOBAL validate_password.length = 4; SET GLOBAL validate_password.policy = LOW;，但仅限重置窗口内
真正关键的不是“怎么改密码”，而是“改给谁看”——host、plugin、password_policy 三者必须对齐，缺一不可。生产环境操作前，建议先在测试库上完整走一遍流程，把命令和预期响应都录下来。
