SQL详解之DCL - 数据控制语言完整指南
引言
数据库里通常会有多个应用、多个用户同时访问,如果某个临时账号就能删库、查密码表,那后果不堪设想。
数据库的三种核心语言里,DDL 负责建结构,DML 负责处理数据,而 DCL(数据控制语言)专门解决“谁能碰什么数据、能碰多少”的问题,堪称数据库的“安全守门员”。
这篇文章会从 DCL 的基础概念讲起,分别用 MySQL 和 PostgreSQL 实操演示怎么管理用户、怎么授权和收权,最后给出一套直接可用的安全规范,帮你从零构建安全的数据库访问体系。
1. DCL基础扫盲
1.1 DCL是什么?
DCL 就像数据库的门禁+房卡系统:
- GRANT → 给别人发房卡(授予对象权限)
- REVOKE → 收走房卡(撤销已给的权限)
- DENY → 把人拉黑(部分数据库支持,覆盖所有授权)
只要用好这三板斧,就能精确控制每个数据库操作的安全边界。
1.2 常用权限表
无论 MySQL 还是 PostgreSQL,核心权限的含义都差不多,记住这张表就行:
2. 先建好「人」:用户/角色管理
2.1 MySQL 用户管理(5.7+ 通用,8.0+ 增强)
MySQL 在 8.0 之前,“用户”和“角色”是分开的,8.0 之后才统一成类似 PostgreSQL 的模型。
这里先用最通用的方式演示。
核心操作
2.2 PostgreSQL 用户/角色管理(原生统一!)
PostgreSQL 里没有单独的“用户”命令,所有账号都是带有不同属性的“角色”:
- 能登录的叫
LOGIN角色(其实就是用户) - 不能登录的叫
NOLOGIN角色(用于分组)
核心操作
3. 再管好「权限」:GRANT / REVOKE
3.1 MySQL 权限授予(Host 别漏!)
MySQL 的权限是绑定到 User@Host 上的,漏写 Host 很容易导致授权不生效。
常用场景
3.2 MySQL 权限撤销
3.3 PostgreSQL 权限授予(别忘了先给 schema 的 USAGE!)
PostgreSQL 有一个极容易踩的坑:必须显式授予 schema 的 USAGE 权限,否则即使拥有表权限,也看不见表。
常用场景
3.4 PostgreSQL 权限撤销
4. 安全最佳实践(必看!别踩坑)
4.1 永远遵循「最小权限原则」
两条红线别碰:
- 不给应用账号库级
ALL PRIVILEGES - 不让应用账号成为
SUPERUSER
MySQL 示例:标准电商应用账号
4.2 用「角色(组)」批量授权
不要逐个给员工授权!先建组(NOLOGIN 角色),把权限全部授予组,最后把用户加入组。
PostgreSQL 示例:标准公司权限体系
4.3 限制登录来源
- MySQL 严格设置
Host字段,非必要不给@'%' - PostgreSQL 通过
pg_hba.conf配置文件控制 IP 范围,同样别全开放
5. MySQL vs PostgreSQL DCL 核心差异(一分钟速查)
相关教程
总结
DCL 就是数据库的“安全盾牌”,记住三个要点就够用:
- 先建角色(组),批量授权,别挨个给用户发权限
- 永远遵循最小权限原则,应用账号只给必要的表级操作
- 限制登录来源,并且定期审查权限列表
MySQL 的 DCL 简单直接,适合快速上线;PostgreSQL 的 DCL 更精细强大,适合对安全要求更高的场景。选对工具,用好 DCL,你的数据库就能又稳又安全。

