服务端程序中数据库用root？

绝对不建议在正式的服务端程序中使用 root 账号连接数据库。

这是一个非常经典且严重的安全反模式。以下是具体原因、潜在风险以及正确的做法：

为什么不能用 root？

1. 权限过大（最小权限原则）

   • root 拥有数据库的最高权限，包括创建/删除库表、修改系统配置、管理用户、甚至执行危险操作（如清空所有数据）。
   • 如果服务端代码出现漏洞（如 SQL 注入），攻击者一旦利用该漏洞，就能直接获取 root 权限，从而彻底控制整个数据库服务器。

2. 安全边界模糊

   • 生产环境通常涉及多个应用或模块。如果使用 root，所有应用共享同一个超级管理员身份，无法区分是哪个业务出了问题，也无法进行细粒度的审计。

3. 合规与审计风险

   • 大多数安全合规标准（如等保、PCI-DSS、GDPR）都明确要求禁止在生产环境中使用默认超级管理员账号访问数据库。

4. 灾难性后果

   • 如果代码中存在逻辑错误（例如误删数据的 SQL 语句），使用 root 会导致整个数据库瞬间被破坏，且可能没有回滚机会。

正确的做法是什么？

你应该遵循 “最小权限原则” (Principle of Least Privilege)，为每个应用程序创建一个专用的数据库用户。

1. 创建专用用户

为该服务创建一个独立的账号（例如 app_user），并仅授予其完成业务所需的最小权限。

MySQL 示例：

-- 1. 创建专用用户 (限制只能从特定 IP 登录)
CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'StrongPassword123!';

-- 2. 授权：只给特定数据库的读写权限
GRANT SELECT, INSERT, UPDATE, DELETE ON my_production_db.* TO 'app_user'@'192.168.1.%';

-- 3. 刷新权限
FLUSH PRIVILEGES;

注意：如果该服务需要创建临时表或视图，可以额外授予 CREATE, DROP, INDEX 等权限，但绝不给 ALL PRIVILEGES。

2. 在代码中配置

将连接信息配置在环境变量或安全的配置中心（如 Kubernetes Secrets, AWS Secrets Manager, HashiCorp Vault）中，而不是硬编码在代码里。

# 示例：application.yml 或 .env
database:
  host: db.example.com
  port: 3306
  user: app_user      # 专用账号
  password: ${DB_PASSWORD} # 从环境变量读取
  database: my_production_db

3. 特殊情况说明

• 开发/测试环境：虽然为了图方便有时会用 root，但也建议养成良好习惯，尽量使用受限账号，以便尽早发现代码中的权限问题。
• 运维脚本：只有临时的运维维护脚本（如备份、恢复）可以使用 root，且这些脚本应严格限制运行环境和调用频率。

总结

永远不要在生产环境的业务代码中使用 root 连接数据库。创建一个权限受限的专用用户，不仅能大幅降低安全风险，还能让故障排查和权限管理更加清晰可控。