运行mysql_secure_installation前必须确认MySQL服务已启动并可本地连接，因其本质是连接本地实例执行SQL；若服务未运行或socket路径异常（如CentOS 8+默认/var/lib/mysql/mysql.sock），将报错无法连接。
运行 mysql_secure_installation 前必须确认服务已启动且能本地连接
脚本本质是连接本地 MySQL 实例执行 SQL 操作，如果 mysqld 没在运行，或配置了 bind-address = 127.0.0.1 但 socket 文件路径异常（如 CentOS 8+ 默认用 /var/lib/mysql/mysql.sock），就会报错 Can't connect to local MySQL server through socket。
实操建议：
- 先执行
systemctl status mysqld确认状态为active (running) - 若提示 socket 错误，可加
--socket=/var/lib/mysql/mysql.sock显式指定（路径可通过mysqld --help --verbose 2>/dev/null | grep socket查） - 不推荐在脚本运行时手动修改
my.cnf，避免权限表刷新失败
mysql_secure_installation 中密码验证插件（VALIDATE PASSWORD）要不要启用？
MySQL 5.7+ 默认不加载该插件，但 mysql_secure_installation 会主动询问是否安装。启用后，后续设置的 root 密码必须满足最低强度（如长度、大小写、数字、特殊字符组合），否则报错 Failed! Password validation failed.。
实操建议：
- 生产环境建议启用，尤其当 root 密码需长期使用时
- 若跳过启用，后续可用
INSTALL COMPONENT "file://component_validate_password";手动加载 - 插件策略由系统变量
validate_password.policy控制，MEDIUM是较平衡的选择 - 注意：启用后所有新用户密码都受约束，不只是 root
脚本默认清理的“匿名用户”和“test 数据库”为什么必须删？
MySQL 初始安装会创建 ''@'localhost' 这类空用户名账户，任何本地用户只要不指定用户名就能以匿名身份登录；同时存在 test 库及 test_% 模糊权限，意味着任意用户可读写测试库——这两项在渗透扫描中属于高危项。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
实操建议：
- 脚本第 2 步“Remove anonymous users?” 和第 4 步“Remove test database and access to it?” 务必选
Y - 删完可手动验证：
SELECT user, host FROM mysql.user WHERE user = '';应返回空集 - 删
test库不影响业务，它只是示例用途；若误删了自建的test_xxx库，脚本不会动——它只删显式名为test的库
禁止 root 远程登录后，如何让应用安全连接数据库？
脚本第 3 步“Disallow root login remotely?” 选 Y 后，root@'%' 账户会被删除，但 root@localhost 仍保留。这意味着你不能再用 mysql -h your-server-ip -u root -p 连接，但应用也不该用 root。
实操建议：
- 立即创建专用用户，例如：
CREATE USER 'app_db'@'192.168.10.%' IDENTIFIED BY 'a_strong_pass_2026!'; - 只授权必要库表：
GRANT SELECT, INSERT, UPDATE ON myapp.* TO 'app_db'@'192.168.10.%'; - 避免用
'%'通配 host，优先写子网段或具体 IP；若必须跨公网，应前置代理或跳板机，而非放开 root 远程 - 防火墙仍需放行 3306（或自定义端口），但仅限可信源 IP 段
真正的加固不是跑完脚本就结束。比如 mysql_secure_installation 不会动 my.cnf 里的 skip-networking 或 default_authentication_plugin，也不会关掉 INFORMATION_SCHEMA 的敏感列暴露——这些得靠后续手动审计和最小权限原则持续收敛。
