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权限，这种细节比密码策略更容易漏掉。
