SQL权限分级设计核心是“最小权限原则+环境隔离”，需按环境分设独立账号、粒度控制到表与操作级别、用角色统一管理权限，并通过自动化与审计持续收敛权限。
SQL权限分级设计核心是“最小权限原则+环境隔离”，开发、测试、生产环境必须严格分离账号和权限，不能共用同一套凭证。
按环境划分独立数据库账号
每个环境（开发/测试/生产）使用完全独立的数据库用户，禁止跨环境复用账号。比如：
- dev_user：仅能访问 dev_db，无 DROP、TRUNCATE、ALTER 权限
- test_user：可读写 test_db，允许执行 INSERT/UPDATE/DELETE，但禁止建表或改结构
- prod_app：仅开放应用所需表的 SELECT/INSERT/UPDATE（不含 DELETE），且限定在 prod_db 内；DBA 单独维护 prod_dba 账号，用于运维操作
权限粒度控制到表与操作级别
避免直接 GRANT ALL ON *.*。应明确指定库、表、操作类型：
- 开发账号通常只需 SELECT、INSERT、UPDATE，且限制在自己负责的模块表（如 user_profile、order_temp）
- 测试账号可额外允许 TRUNCATE 临时表，但禁用对日志表、配置表的写入
- 生产应用账号严禁 GRANT FILE、PROCESS、SUPER 等高危权限；敏感字段（如 password_hash、id_card）可通过视图过滤或列级权限（如 MySQL 8.0+ 的 COLUMN PRIVILEGES）进一步限制
用角色（Role）统一管理同类权限
MySQL 8.0+ / PostgreSQL / SQL Server 均支持角色机制，推荐用角色解耦权限与用户：
- 创建 role_dev_reader、role_test_writer、role_prod_app 三个角色
- 将具体权限（如 SELECT ON dev_db.users）赋予角色，再把角色授予对应环境的用户
- 权限变更时只需调整角色定义，无需逐个修改用户，降低误操作风险
自动化与审计不可少
人工维护易出错，建议配合工具落地：
- 用 Ansible/Terraform 管理账号创建脚本，确保各环境权限声明即代码（IaC）
- 开启数据库审计日志（如 MySQL general_log 关闭，但启用 audit_log 插件），重点记录 DDL 和高危 DML 操作
- 定期扫描账号权限（如用 pt-show-grants 或自定义 SQL 查询 mysql.user + mysql.db 表），比对是否符合基线策略
