mysql 不建议使用 root 用户进行远程登录，因其拥有最高权限且远程暴露风险极高，易被攻击者利用导致系统沦陷；应禁用 root 远程访问，为应用创建最小权限专用账号，并通过 ssh 隧道、防火墙等加固措施保障安全。
MySQL 不建议使用 root 用户进行远程登录，核心原因在于 root 是数据库的最高权限账户，一旦被攻击者获取远程访问权限，整个数据库系统将面临严重安全风险。
root 账户权限过大，远程暴露风险极高
root 用户默认拥有所有数据库的全部权限（如 CREATE、DROP、delete、FILE、GRANT OPTION 等），包括读写任意数据、执行系统命令（如通过 LOAD DATA INFILE 或 select … INTO OUTFILE 操作文件）、甚至提权到操作系统层面（在特定配置下）。若允许 root 远程登录，相当于把“万能钥匙”直接放在公网入口，一旦密码弱、被爆破或中间人劫持，后果不可控。
远程连接本身增加攻击面
开启 MySQL 的远程访问（如 bind-address 设为 0.0.0.0 或注释掉）会使服务监听在公网 IP 上，容易被扫描工具发现。攻击者可尝试暴力破解、利用已知漏洞（如 CVE-2012-2122、旧版本认证绕过）、或发起拒绝服务攻击。而 root 账户正是这些攻击的首要目标。
缺乏最小权限原则和操作审计能力
生产环境中应遵循“最小权限原则”：谁用、什么业务、需要哪些库/表、仅授予必要权限。root 远程登录无法区分操作来源与意图，也难以关联具体责任人；日志中虽有记录，但一旦被篡改或未启用通用查询日志（general_log），就难追溯异常行为。相比之下，为应用单独创建受限账号（如只对 order_db.orders 表有 SELECT/INSERT 权限），能有效限制破坏范围。
更安全的替代方案
- 禁用 root 远程登录：确保 mysql.user 表中 root 用户的 host 字段为 ‘localhost’（非 ‘%’ 或具体IP），执行 FLUSH PRIVILEGES;
- 为每个应用或服务创建专用账号，限定 host（如 ‘app-server-01′ 或内网网段 ‘192.168.10.%’），并严格授权
- 强制使用强密码 + 定期轮换，避免密码复用
- 通过 SSH 隧道或跳板机访问数据库，不直接开放 MySQL 端口（3306）到公网
- 启用防火墙（如 iptables / ufw）限制仅允许可信 IP 访问 3306 端口
- 开启 MySQL 的 audit log（企业版）或使用插件（如 mariadb 的 server_audit）增强行为追踪
不复杂但容易忽略：安全不是靠“没人来试”，而是让即使有人接触到了，也无法越界。限制 root 远程登录，是最基础也最关键的防线之一。