SQL权限控制须遵循最小权限原则，按角色分层授权，精确到列与行，写操作严格隔离，禁用高危语句，并定期审计回收闲置权限。
SQL权限控制的核心是“按需赋权”，不是谁都能用SELECT，更不能让业务账号拥有DROP TABLE能力。最小权限原则不是限制开发，而是守住数据安全的底线——只给完成任务所必需的权限，不多一分，不少一厘。
按角色分层授权，不按人头授予权限
直接给用户账号赋权容易失控，应先抽象出稳定的角色（如report_reader、order_writer、admin_backup），再把权限赋予角色，最后把角色分配给用户。这样权限变更只需调整角色定义，无需逐个修改用户。
- 建角色：
CREATE ROLE report_reader; - 授查询权（仅指定库表）：
GRANT SELECT ON sales.orders TO report_reader; - 绑定用户：
GRANT report_reader TO 'bi_user'@'%';
精确到列与行，避免“全表可读”惯性
敏感字段（如身份证、手机号、薪资）默认不可见；高频但低敏字段（如订单号、状态）才开放。MySQL 8.0+ 支持列级权限，PostgreSQL 可通过视图+行级策略（RLS）实现行级过滤。
- MySQL 列级示例：
GRANT SELECT(order_id, status, amount) ON sales.orders TO 'app_user'@'%'; - PostgreSQL 行级示例：为
user_id = current_setting('app.current_user_id')自动加WHERE条件，用户查不到他人数据
写操作严格隔离，禁用高危语句默认权限
INSERT/UPDATE/DELETE必须限定在明确业务场景下，且禁止跨表批量更新。所有DROP、TRUNCATE、ALTER类操作一律禁止授予应用账号，仅DBA通过审批流程临时启用。
- 写权限只给具体表：
GRANT INSERT, UPDATE(status, remark) ON sales.orders TO 'order_service'@'10.20.%'; - 用存储过程封装复杂逻辑，权限只给执行过程（
EXECUTE），不放开底层表写权限 - 应用连接字符串中禁止使用
root或sa等超级账号
定期审计与自动回收，权限不“一劳永逸”
权限不是设完就结束。每月扫描未登录超90天的账号、长期未使用的角色、超出业务范围的权限组合。可用脚本自
动比对“当前权限”和“最小权限清单”，标记异常项。
- MySQL 查闲置账号：
SELECT user, host FROM mysql.user WHERE password_last_changed - 生成权限报告：
SELECT grantee, table_schema, table_name, privilege_type FROM role_table_grants WHERE role_name = 'report_reader'; - 新员工入职：仅继承预置角色，不复制他*限
最小权限不是靠感觉判断，而是靠角色定义、列/行约束、操作白名单和周期审计四层落地。做得细，风险才真的可控。
