生产环境不应直接使用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_2024';<br>GRANT SELECT, INSERT, UPDATE, DELETE ON `wp_*`.* TO 'wp_app'@'localhost';<br>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权限，这种细节比密码策略更容易漏掉。
