SQL权限模型核心是“最小权限原则+角色分层管理”：按职责设角色（如录入员、分析师、DBA、开发测试员），通过视图/存储过程封装操作，分环境分库分表控制粒度，并配套审计与定期复核机制。
SQL 数据库权限模型设计核心是“最小权限原则”+“角色分层管理”，避免直接给用户授予权限，而是通过角色统一分配，再把角色赋予用户。
按职责划分角色，不按人设权限
比如区分 数据录入员、报表分析师、运维DBA、开发测试员 等角色。每个角色只拥有完成本职工作必需的权限：
- 数据录入员：仅对指定表有 INSERT、UPDATE（可能限制 UPDATE 字段）和 SELECT 权限，禁止 DROP、DELETE 全表、访问日志表
- 报表分析师：SELECT 权限覆盖多个业务视图或汇总表，但禁止写操作，不开放系统表（如 mysql.user）
- 运维DBA：拥有 CREATE/ALTER/DROP DATABASE、备份恢复相关权限（如 LOCK TABLES、RELOAD），但默认不授予应用数据库的 SELECT 权限，防止越权查业务数据
- 开发测试员：在测试库有全部权限，但在生产库仅允许执行预审过的只读视图或存储过程，禁止直连生产表
用视图和存储过程封装敏感操作
不直接开放基础表权限，而是通过可控接口降低风险：
- 把多表 JOIN 或含复杂条件的查询封装成视图，授予 SELECT 视图权限，隐藏底层结构和敏感字段（如脱敏手机号）
- 将 INSERT/UPDATE/DELETE 封装进存储过程，并在过程中校验业务规则（如余额不能为负）、记录操作日志；只授 EXECUTE 权限，不给表
级 DML 权限
- 例如：创建
proc_transfer_funds 处理转账，内部检查账户状态、余额、风控标记，调用者只需 EXECUTE，无法绕过逻辑直接改表
分环境、分库、分表控制粒度
权限需随环境严格隔离，且支持细粒度收敛：
- 生产库禁用 root 连接，所有应用使用独立账号，账号密码定期轮换，连接 IP 白名单限制（如只允许应用服务器网段）
- 按业务域分库（如 order_db、user_db、report_db），不同团队角色只访问对应库；跨库查询通过授权视图或中间服务，不开放跨库 SELECT
- 对敏感表（如 user_info）单独授权，或进一步按列限制（如 MySQL 8.0+ 支持列级权限：GRANT SELECT(id, name, created_at) ON user_db.user_info TO 'analyst'@'%'）
审计与定期复核机制不可少
权限不是设完就不管，必须配套可观测性和治理流程：
- 开启数据库审计日志（如 MySQL general_log 关键操作，或企业版 Audit Plugin），记录谁、何时、执行了什么语句
- 每季度自动扫描：哪些账号长期未登录、哪些角色权限超出当前岗位说明书、是否存在冗余 GRANT（如重复授权同一表）
- 员工转岗/离职时，立即回收其所属角色，而非逐条删权限；新员工入职，只加入预定义角色，不临时加权
权限模型不是一次性配置，而是一套持续演进的策略。从角色抽象开始，靠视图和过程收口，借环境与对象分级隔离，再用审计兜底——这样既保障安全，又不拖慢开发和运维效率。
