运行 mysql_secure_installation 前必须先启动 MySQL 服务，否则报错“Can't connect to local MySQL server through socket”；Linux 用 systemctl start mysqld 或 mysql，macOS 用 brew services start mysql，Windows 在服务管理器中启动 MySQL80。
运行 mysql_secure_installation 前必须先启动 MySQL 服务
很多人卡在第一步：直接执行 mysql_secure_installation 报错 Can't connect to local MySQL server through socket。这不是脚本问题，是服务根本没起来。
实操建议：
- Linux（systemd）下先运行
sudo systemctl start mysqld（CentOS/RHEL）或sudo systemctl start mysql（Ubuntu/Debian） - 确认状态：
sudo systemctl status mysqld或sudo systemctl status mysql，看到active (running)再继续 - macOS 用 Homebrew 安装的，要先
brew services start mysql - Windows 用户注意：MySQL Installer 默认勾选了“Configure MySQL Server”，但若跳过，需手动在服务管理器中启动
MySQL80（或对应服务名）
mysql_secure_installation 会修改 root 密码，且不提示旧密码
MySQL 5.7+ 默认启用 auth_socket 插件验证 root 用户，这意味着你用系统用户登录时不需要密码——但 mysql_secure_installation 不走这条路，它强制走密码认证，并默认把 root 密码设为空或要求你重设。
常见错误现象：
- 执行中途报错
Access denied for user 'root'@'localhost'，尤其在跳过密码设置后尝试登录 - 完成后用
mysql -u root -p登录失败，因为脚本已把密码设为新值，而你可能忘了记下来
实操建议：
- 首次运行时，第 1 步“Set password for root ?”务必选
Y，并输一个强密码（别留空） - 如果已经因空密码锁死，需临时跳过权限检查重启 MySQL：
sudo mysqld_safe --skip-grant-tables &，再进mysql -u root手动更新mysql.user表中的authentication_string - 脚本不会告诉你新密码存哪——自己记在安全的地方，别依赖“我待会儿再设”
删除匿名用户和测试库不是可选项，而是默认开启的安全动作
mysql_secure_installation 的第 2–4 步（Remove anonymous users / Disallow root login remotely / Remove test database）全都是 Y/N 提示，但很多人一路狂按 Enter，结果默认选了 Y——这本身没问题，但容易忽略后果。
使用场景与影响：
- 开发机本地单机用：删匿名用户和测试库完全安全；但若你用
mysql -u '' -p习惯性空用户名登录，之后就再也登不进去了 - 远程管理需求：选
Y禁止 root 远程登录后，mysql -h your-server-ip -u root -p必然失败——得额外创建带host限定的普通用户 - 测试库（
test）被删后，某些老脚本或 ORM 初始化逻辑可能报Unknown database 'test'，不是崩溃，但会中断流程
MySQL 8.0+ 的 mysql_secure_installation 不再支持旧密码策略
如果你在 MySQL 8.0+ 上运行该脚本，会发现它不再问“Use VALIDATE PASSWORD plugin?”，而是直接启用插件并强制最低强度——这是 8.0 的默认行为，不是脚本变“智能”了，是底层策略变了。
参数差异与坑点：
- 输入密码时若太短（如
123），会直接拒绝，提示Failed! Password validation failed.，不是警告，是中断流程 - 插件策略由
validate_password.policy控制，默认是MEDIUM，要求至少 8 位 + 大小写字母 + 数字 + 特殊字符 - 不想被卡住？提前在
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf中注释掉或调低该配置，再运行脚本 - 但注意：降低策略后，脚本仍可能因其他校验（如用户名是否含特殊字符）失败，别迷信“设成 LOW 就万事大吉”
最常被忽略的一点：脚本执行完不会自动重载权限表，FLUSH PRIVILEGES 是它内部做的，但如果你中途 Ctrl+C 中断，或者脚本因密码策略退出，那部分更改（比如禁用匿名用户）可能只写了一半——此时别急着重启，先连进去查 SELECT User,Host FROM mysql.user; 确认状态。
