mysql_secure_installation运行后密码仍为空，因脚本不自动读取首次启动生成的临时root密码，须先手动登录并重置密码才能正常执行；后续步骤需谨慎处理匿名用户、远程root访问、test库及已有用户权限。
mysql_secure_installation 运行后密码还是空？
默认安装的 MySQL（尤其是 5.7+）在首次启动时会生成一个临时 root 密码，但 mysql_secure_installation 并不会自动读取它——你得手动登录一次，再运行脚本。否则脚本直接报错 Access denied for user 'root'@'localhost'，然后卡住。
实操建议：
- 先查临时密码：
sudo grep 'temporary password' /var/log/mysqld.log（CentOS/RHEL）或sudo cat /var/log/mysql/error.log | grep 'temporary'（Ubuntu/Debian） - 用该密码登录：
mysql -u root -p，然后立刻执行ALTER USER 'root'@'localhost' IDENTIFIED BY '你的强密码'; - 退出后，再运行
mysql_secure_installation，此时它才能正常连接并交互式加固
脚本里选“Remove anonymous users”到底删了啥？
MySQL 默认建了几个匿名用户（''@'localhost'、''@'hostname'），它们没用户名，只靠 host 匹配，权限可能意外放通。比如本地任意程序连 MySQL 不输用户名也能进——尤其在 Docker 或共享主机环境下很危险。
实操建议：
- 选
Y删除是安全的，除非你明确依赖匿名用户做某些老脚本兼容（极少见） - 删完记得验证：
SELECT User,Host FROM mysql.user WHERE User='';应返回空集 - 注意：这个操作不影响 root 或其他已命名用户，也不改任何数据库数据
Disallow root login remotely 为什么不能无脑选 Y？
选 Y 会把 'root'@'%' 和 'root'@'::1' 全干掉，只留 'root'@'localhost'。问题在于：很多运维工具（如 Navicat、DBeaver）、监控系统、甚至部分云平台控制台，都是通过 TCP 连 MySQL 的——它们走的是 127.0.0.1（不是 localhost），而 MySQL 把 127.0.0.1 当作远程 host 处理，不匹配 localhost 的 socket 认证规则。
实操建议：
- 如果必须远程管理，别急着选 Y；先手动限制 root 远程访问：
DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1'); - 再为管理需求单独建一个低权限账号：
CREATE USER 'admin'@'%' IDENTIFIED BY '强密码'; GRANT SELECT,SHOW VIEW ON *.* TO 'admin'@'%'; - 最后刷新：
FLUSH PRIVILEGES;
Test database 被删后，为什么有些程序启动失败？
mysql_secure_installation 默认删掉 test 库和 test_% 开头的库。但不少开发框架（比如旧版 Laravel、某些 Django 测试配置）默认用 test 作测试库名，或者代码里硬写了 USE test;。删完就抛 Unknown database 'test' 错误。
实操建议：
- 生产环境删它是对的，但上线前务必检查应用的数据库配置、初始化 SQL、测试脚本是否依赖
test - 临时方案：删完后手动重建
test库（仅限开发/测试机）：CREATE DATABASE test; - 更稳妥做法：把应用里的
test替成真实业务库名，或统一用CREATE DATABASE IF NOT EXISTS test;初始化
真正容易被忽略的，是 mysql_secure_installation 不动 existing user 权限——它只处理 root、anonymous、test 相关项。如果你之前手动建过用户，或者用一键包（如 XAMPP、MAMP）装过，那些账号的密码强度、host 通配符（%）、甚至空密码都还在。加固不是点几下就完事，得配合 SELECT User,Host,authentication_string FROM mysql.user; 手动巡检。
