生产环境不应直接使用 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';
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 权限，这种细节比密码策略更容易漏掉。
