生产环境不应直接使用root账号，需删除冗余root实例、创建最小权限专用账号、启用密码强度策略并限制登录方式。例如保留root@localhost、禁用root@%、为应用分配如wp_app等受限账号，并配置validate_password插件与caching_sha2_password认证。

root用户默认有全部权限，但不等于该用就用

MySQL安装后，root用户通常拥有ALL PRIVILEGES并可从localhost或127.0.0.1登录，但这只是初始状态。生产环境直接用root执行应用连接、脚本操作或远程管理，会放大攻击面——一旦密码泄露或SQL注入得手，数据库即完全失守。

• 应用配置文件里写root账号和密码，等于把钥匙挂在门把手上
• root@%（允许任意主机登录）比root@localhost危险得多，尤其没开防火墙时
• MySQL 8.0+ 默认启用validate_password插件，但root密码仍可能被设为弱口令，插件不自动拦截

删掉多余root实例，只保留必要登录路径

MySQL允许同名用户对应不同host，root@localhost和root@127.0.0.1是两个独立账户。检查当前所有root记录：

SELECT User, Host FROM mysql.user WHERE User = 'root';

常见冗余组合包括：root@%、root::1、root@192.168.%。只需保留一个最严格的：

• 开发机：留root@localhost即可，禁用root@127.0.0.1（Unix socket优先，更安全）
• 服务器：若必须远程维护，仅开root@10.0.1.5（运维跳板机IP），绝不用%
• 执行删除前先确认自己能用其他高权限账号登录，避免锁死：DROP USER 'root'@'%';

用专用账号替代root做日常操作

给应用、备份脚本、监控工具分配最小权限账号，比“禁用root”更实际。例如WordPress需要的权限远小于ALL：

CREATE USER 'wp_app'@'localhost' IDENTIFIED BY 'strong_pass_2025';
GRANT SELECT, INSERT, UPDATE, DELETE ON `wp_*`.* TO 'wp_app'@'localhost';
FLUSH PRIVILEGES;

关键点：

• 用GRANT ... ON database_name.*而非ON *.*，避免跨库越权
• 敏感操作如DROP TABLE、CREATE USER、FILE权限一律不放给应用账号
• MySQL 8.0+ 支持角色（CREATE ROLE），可先建backup_role再授权给mysqldump_user，便于批量调整

强制root密码强度与登录方式限制

仅设复杂密码不够，要让MySQL主动拒绝弱口令和不安全登录：

• 启用密码验证插件：INSTALL PLUGIN validate_password SONAME 'validate_password.so';，然后设SET GLOBAL validate_password.policy = STRONG;
• 禁止空密码：SET GLOBAL validate_password.check_user_name = ON;（防止用户名作密码）
• 关闭旧协议认证：ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'xxx';（MySQL 8.0+默认，比mysql_native_password更安全）
• 如需SSH隧道访问，直接禁用TCP端口监听：skip-networking或bind-address = 127.0.0.1，逼迫所有远程操作走加密通道

真正难的是权限收敛后的兼容性验证——有些老脚本硬编码了root，改账号后报Access denied for user不是权限问题，而是它试图连127.0.0.1却只给了localhost权限，这种细节比密码策略更容易漏掉。