列名写错不会静默失败：MySQL和PostgreSQL报列不存在错误，SQL Server拒绝执行；列级GRANT必须显式列出真实存在的基表列，不支持通配符。
GRANT 时列名写错会静默失败吗
不会静默失败，但行为因数据库而异——MySQL 和 PostgreSQL 都会报错，SQL Server 则直接拒绝执行。关键在于：列级 GRANT 必须显式列出存在的列名，且不能包含视图字段、计算列或不存在的列。
- PostgreSQL 报错：
column "xxx" does not exist in table "yyy" - MySQL 8.0+ 报错：
Unknown column 'xxx' in 'field list' - SQL Server 要求列必须在
GRANT SELECT (col1, col2)中真实存在，否则报Msg 3702, Level 16 - 别用通配符（如
*或ALL COLUMNS）——所有主流数据库都不支持列级授权用通配符
表级 GRANT 后还能单独 revoke 某列吗
可以，但要注意权限叠加逻辑：列级权限是独立于表级权限的“额外约束”，不是子集关系。撤销列权限不影响表级权限，但用户仍能通过表级权限访问该列——除非你先撤掉表级权限。
- PostgreSQL 中，
REVOKE SELECT (salary) ON employees FROM alice仅移除列级许可，alice若仍有SELECT ON employees，依然能查salary - MySQL 不支持列级
REVOKE，只能靠DROP USER或重建权限；实际中建议用角色隔离，避免混用表级和列级 - SQL Server 允许混合，但列级
DENY优先级高于表级GRANT，所以DENY SELECT (ssn) ON emp TO bob会真正屏蔽该列
WHERE 条件里用到的列是否需要单独授权
需要。如果查询带 WHERE salary > 5000，即使只 SELECT name，数据库仍需读取 salary 列来计算条件——没授权就会报错。
- PostgreSQL 报：
permission denied for column salary on relation employees - MySQL 报：
SELECT command denied to user ... for column 'salary' in table 'employees' - 常见疏漏：前端分页查询加了
ORDER BY created_at，但只给了id和name列权限 → 直接失败 - 解决办法不是多授列，而是让应用层改写逻辑（比如用已授权列做排序），或统一用行级安全策略（RLS）替代列级控制
列级权限在视图上怎么生效
不自动继承。视图定义里的列权限由底层表决定，但用户对视图的列级授权必须单独授予，且只作用于视图本身，不影响基表。
- 创建视图
CREATE VIEW emp_public AS SELECT id, name FROM employees后，必须显式执行GRANT SELECT (id, name) ON emp_public TO user1 - 即使
user1对employees有全表SELECT，也不代表能查emp_public—— 视图是独立对象 - PostgreSQL 中，若视图用了函数或表达式（如
UPPER(name)），无法对其结果列授权，只能授整个视图 - MySQL 8.0+ 支持视图列授权，但语法必须严格匹配视图定义中的列名，不能用别名
列级权限看似精细，实则容易在 JOIN、子查询、函数调用、视图嵌套这些地方漏授权。最稳妥的做法是：先跑通最小查询，再逐个加 WHERE、ORDER BY、JOIN，每步都验证错误信息——别依赖“应该可以”。
