SQL 表级与列级权限设计实践

表级授权优先，列级仅用于明确隔离场景；mysql列权限需显式引用字段才生效；sql server用动态数据掩码而非deny；迁移时易漏元数据及序列权限。

postgresql 中 GRANT 到表还是列，怎么选

表级授权够用时别急着切到列级——它不光多写几行命令，还会让权限逻辑变模糊，尤其当多个 GRANT 重叠时，pg_catalog.pg_attribute 和 pg_catalog.pg_class 的实际生效顺序容易误判。

常见错误现象：select * FROM t 报 permission denied for column xxx，但单独查其他字段又正常；或者 INSERT 失败却没提示具体哪列被拦住。

• 默认走表级：对普通业务表，先用 GRANT SELECT ON table t TO u，够用就停手
• 列级只在明确隔离场景下启用：比如用户只能看 name 和 status，但不能碰 salary 或 email
• 列级 GRANT 不会自动覆盖表级拒绝（REVOKE），必须显式 REVOKE SELECT ON TABLE t FROM u 再逐列授，否则可能被表级权限“兜底”放行
• 注意 INSERT 和 UPDATE 的列级权限是独立检查的：哪怕只改一列，也得对该列有 UPDATE 权，且不含该列的 INSERT 语句仍需整行权限（除非用 INSERT (col1, col2) VALUES (...) 显式限定）

MySQL 8.0 的列权限为什么经常失效

根本原因是 MySQL 的列权限只在语句显式引用列名时触发，SELECT *、UPDATE t SET c = c + 1 这类写法会直接跳过列权限检查，退回到表级判断。

使用场景受限明显：它适合审计要求强、且应用层能保证所有 SQL 都显式列出字段的系统；不适合 ORM 自动生成 * 或动态拼接字段的项目。

• 必须用 GRANT SELECT (col1, col2) ON db.t TO 'u'@'%'，不能省略括号里的列名列表
• SHOW GRANTS FOR 'u'@'%' 输出里如果出现 GRANT SELECT(col1) ON `db`.`t`，说明列权限已生效；但若同时存在 GRANT SELECT ON `db`.`t`，后者会完全覆盖前者
• 性能影响小，但权限元数据缓存刷新较慢：改完列权限后，连接需断开重连，或等 FLUSH PRIVILEGES（仅部分版本可靠）
• 兼容性坑：MySQL 5.7 不支持列级 INSERT 权限，8.0 才补全；且 REVOKE 列权限时不能写 REVOKE SELECT (c) ON t FROM u，必须用 REVOKE ALL PRIVILEGES ON t FROM u 再重授，否则残留

SQL Server 的 ADD MEMBER 和列掩码怎么配合用

SQL Server 不靠 GRANT 控制列可见性，而是用角色成员身份 + 行级安全（RLS）或动态数据掩码（DDM）。想实现列级读限制，优先选 DDM，而不是硬塞一堆 DENY SELECT ON COLUMN::c TO r。

常见错误现象：加了 DENY 却发现用户还能查——因为 db_owner 或 sysadmin 角色自动绕过所有列级拒绝；或者掩码规则写了但 SELECT * 返回空字符串，而显式查列名又正常，其实是掩码表达式写错了类型。

• 列掩码必须搭配 ALTER TABLE ... ALTER COLUMN c ADD MASKED WITH (function = 'default()')，不是权限语句
• DENY SELECT ON COLUMN::c TO r 只对非特权用户有效，且一旦用户属于 db_datareader 角色，这个 DENY 就会被忽略（角色权限 > 列拒绝）
• 真正可控的方式是建专用角色（如 app_reader_lite），用 ADD MEMBER 加入用户，再对这个角色设 DDM 或 RLS，避免和内置角色冲突
• 注意 DDM 不加密数据，只是查询时替换输出值；敏感字段如密码哈希仍需额外加密存储

跨数据库迁移时权限脚本最常漏掉什么

不是语法差异，而是隐式依赖的元数据权限——比如 PostgreSQL 的 pg_stat_activity 视图访问权、MySQL 的 performance_schema 表、SQL Server 的 sys.dm_exec_sessions 动态管理视图。这些不显式 GRANT，监控类 SQL 或连接池健康检查就会静默失败。

另一个高频遗漏点：序列（PostgreSQL）、自增列（MySQL）、标识列（SQL Server）的 USAGE 或 SELECT 权限。插入时不显式指定 ID，但底层要读序列当前值，没权限就报 permission denied for sequence。

• PostgreSQL 迁移后务必补：GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO u，并加 ALTER DEFAULT PRIVILEGES 防新序列漏授
• MySQL 要检查 performance_schema 和 information_schema 的 SELECT 权限是否随用户同步过去，尤其用 Percona Toolkit 时容易丢
• SQL Server 注意 VIEW SERVER STATE 和 VIEW database STATE 这两个服务器级权限，它们不在数据库备份里，必须手工赋给登录名
• 所有数据库里，函数/存储过程执行权都独立于表权限：GRANT EXECUTE ON FUNCTION f TO u 不能省，哪怕只调用一次

权限设计真正的复杂点不在语法，而在人——谁该看到什么，往往要翻三遍需求文档、两次线上日志、一次 dba 口述规则才能对齐。别信“按文档配就行”，生产环境里，权限链上任意一环松动，都会变成排查黑洞。