应用直连root是高危操作，因root默认拥有drop database、shutdown、file等高危权限，一旦发生sql注入或配置泄露（如django配置误传github），攻击者可在数分钟内删库、读取服务器文件甚至提权。
为什么应用直连 root 是高危操作
root 账号默认拥有 DROP DATABASE、SHUTDOWN、CREATE USER、FILE 等权限，一旦应用存在 SQL 注入、配置泄露（比如误传 settings.py 到 GitHub），攻击者就能直接删库、读取服务器文件、提权甚至反弹 shell。这不是理论风险——2026 年上半年已有多个团队因 Django 的 DATABASES 配置里硬编码了 'root'@'192.168.%'，被扫描器 3 分钟内清空生产库。
创建最小权限专用账号的实操要点
必须为每个应用单独建用户，且只授其实际需要的权限，禁止跨库、禁止高危语句。
- 用
CREATE USER显式指定 host 范围，例如'app_api'@'10.10.20.%'，避免用'%'（哪怕在内网） -
GRANT时精确到库表：GRANT SELECT, INSERT, UPDATE ON myapp_db.users TO 'app_api'@'10.10.20.%'; - 绝对禁用：
GRANT OPTION、FILE、PROCESS、SUPER、SHUTDOWN—— 这些权限在SHOW GRANTS FOR 'app_api'@'10.10.20.%';中不应出现 - 开发环境也别破例：可用
CREATE USER 'dev'@'localhost' IDENTIFIED BY 'dev_pwd_2026!'; GRANT ALL ON test_%.* TO 'dev'@'localhost';隔离测试库
如何确认 root 已无法被应用误用
不能只靠“没配 root 就安全了”，得验证 MySQL 层是否真切断了路径。
- 查当前所有 root 记录：
SELECT User, Host FROM mysql.user WHERE User = 'root';—— 只应剩'root'@'localhost'，其他如'root'@'%'或'root'@'192.168.1.%'必须DROP USER删除（MySQL 8.0+ 不允许DELETE FROM mysql.user） - 检查应用连接字符串是否含
user=root：Django 的DATABASES、Spring Boot 的spring.datasource.username、Node.js 的 connection URL 都要人工扫一遍 - 临时改密码测试：执行
ALTER USER 'root'@'localhost' IDENTIFIED BY 'x';，再让应用启动——若报Access denied，说明它确实还在连 root；若正常启动，说明已切到专用账号
配置与部署环节容易被忽略的细节
很多团队加固完数据库，却在 CI/CD 或容器启动阶段又把 root 暴露出来。
- Docker 启动时，别用
-e MYSQL_ROOT_PASSWORD=xxx后还让应用连这个 root；应该用该变量初始化，然后脚本里立刻CREATE USER ... GRANT ... DROP USER 'root'@'%' - Ansible/Terraform 自动化部署时，
mysql_user模块必须显式设host: 10.10.20.%和priv: "myapp_db.*:SELECT,INSERT,UPDATE"，不能留空或写"*.*:ALL" - 云数据库（如阿里云 RDS、腾讯云 CDB）控制台里，root 类账号通常不可见，但“高权限账号”可能等价于 root，务必在控制台新建子账号并严格限制 IP 白名单和权限范围
真正卡住应用连 root 的，从来不是某条 SQL，而是上线前那一次 grep -r "root" . 和部署后那一次 SELECT User, Host FROM mysql.user 核对。权限切得再细，只要有一处配置漏掉、一个脚本绕过、一个开发者本地调试时手欠改了配置，防线就垮了。
