表级授权优先，列级仅用于明确隔离场景；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 口述规则才能对齐。别信“按文档配就行”，生产环境里，权限链上任意一环松动，都会变成排查黑洞。
