MySQL未生成临时密码是因为/var/lib/mysql非空导致跳过初始化，需清空目录后用mysqld --initialize --user=mysql手动初始化，或检查日志路径是否为Ubuntu的/var/log/mysql/error.log、macOS的/usr/local/var/mysql/*.err等正确位置。
grep 'temporary password' /var/log/mysqld.log 为什么没结果
不是命令写错了，也不是日志路径记混了，而是根本没生成——MySQL 启动时若检测到 /var/lib/mysql 目录非空（比如残留旧数据、手动删过又没重初始化），mysqld 就会跳过密码生成流程，直接复用已有用户表。此时日志里自然没有 temporary password 这行。
常见诱因包括：
- 之前装过 MySQL 没卸干净，
/var/lib/mysql还留着旧的ibdata1、mysql库等文件 - 用
apt remove mysql-server或yum remove mysql-community-server卸载后，没手动删/var/lib/mysql - 安装后手动执行过
mysqld --initialize但没加--user=mysql，导致初始化失败却无报错
确认日志路径是否真的对
/var/log/mysqld.log 是 CentOS/RHEL 系默认路径，但 Ubuntu/Debian 默认写入 /var/log/mysql/error.log；Homebrew 安装的 macOS 版则在 /usr/local/var/mysql/*.err（如 $(hostname).err）。直接 ls -l /var/log/mysql/ 或 find /var/log -name "*.err" -mtime -7 更可靠。
如果连 .err 文件都不存在，说明 mysqld 根本没成功启动过——检查 systemctl status mysqld（或 mysql）输出里的 Active: 状态和最近的 Failed 行。
mysqld --initialize 手动触发密码生成
清掉残留数据后，必须显式初始化才能让临时密码出现：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先停服务：
sudo systemctl stop mysqld - 删数据目录：
sudo rm -rf /var/lib/mysql - 重建初始化：
sudo mysqld --initialize --user=mysql --datadir=/var/lib/mysql - 重启服务：
sudo systemctl start mysqld
注意：CentOS 8+ 或某些新版包可能要求加 --log-error=/var/log/mysqld.log 显式指定日志路径，否则密码信息会打到 journalctl -u mysqld 里。
跳过权限验证改密码的实操边界
用 skip-grant-tables 能绕过登录，但要注意两点：
- 它只在配置文件中生效，且必须加在
[mysqld]段下；改完要systemctl restart mysqld，不能只reload - 5.7.6+ 版本里，
UPDATE mysql.user改密码已失效，必须用ALTER USER 'root'@'localhost' IDENTIFIED BY 'xxx'，否则登录后仍被锁死 - 改完密码后别忘了删掉
skip-grant-tables并重启，否则数据库等于裸奔
最易忽略的一点：即使你成功执行了 ALTER USER，如果 root 用户的 plugin 字段是 auth_socket（常见于 Ubuntu 的 mysql-server 包），那密码本身无效——得先 ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx' 切换认证方式。
