视图应显式指定SELECT列名而非*，以实现列级权限控制；需单独授予视图SELECT权限，不可依赖基表权限；注意数据库版本差异及角色激活状态。
视图里用 SELECT 列名而不是 *，是列权限控制的起点
直接在视图定义中显式写出需要暴露的列，SELECT user_id, username, created_at FROM users，而不是 SELECT * FROM users。这是最基础也最关键的一步——视图本身不“继承”原表权限，它只暴露你写进 SELECT 的那些字段。如果漏写了某列，哪怕用户对基表有全权，也无法通过该视图查到它。
常见错误是开发时图省事用 *，上线后才发现敏感字段（比如 password_hash、email）被无意暴露。PostgreSQL 和 MySQL 8.0+ 都支持这种列级过滤，但注意：SQL Server 视图虽也支持显式列，但若基表结构变更（如新增列），视图不会自动更新定义，必须手动 ALTER VIEW 重编译，否则可能报错或行为异常。
给视图单独授权，别依赖基表权限
用户能查视图，不等于能查它背后的基表；反过来，用户有基表 SELECT 权限，也不代表能查视图——视图权限必须显式授予。执行 GRANT SELECT ON my_user_view TO 'analyst'@'%'（MySQL）或 GRANT SELECT ON my_user_view TO analyst（PostgreSQL）才是生效的关键动作。
容易踩的坑：
- 误以为给用户授了基表权限就自动能用视图，结果
ERROR: permission denied for relation users（PostgreSQL）或类似拒绝提示 - 在 PostgreSQL 中，视图所有者默认拥有“定义者权限”（
SECURITY DEFINER），但若未显式设置，实际走的是调用者权限（SECURITY INVOKER），此时用户仍需基表权限——除非你明确加CREATE VIEW ... WITH (security_invoker = false)或建完用ALTER VIEW ... SET (security_invoker = false) - MySQL 8.0+ 支持角色（
CREATE ROLE），可把视图权限批量赋给角色再分配给用户，比逐个GRANT更可控
敏感字段真要隐藏？别只靠视图，还得看函数和表达式是否泄露
视图里用 CASE WHEN 或 COALESCE 做字段脱敏（比如把邮箱变成 ***@***.com）看似安全，但要注意：这些表达式本身在查询计划里可见，且如果用户有视图定义权限（pg_get_viewdef() 或 SHOW CREATE VIEW），就能看到逻辑。更隐蔽的风险是：某些数据库允许在视图中调用自定义函数，而函数体若含敏感操作（如查另一张配置表），可能绕过列限制。
实操建议：
- 避免在视图里调用非确定性函数（如
NOW()、RANDOM()）或访问其他受控表——这会让权限模型变复杂 - MySQL 中，
SELECT权限对视图生效，但SHOW CREATE VIEW需额外SELECT或SHOW VIEW权限；PostgreSQL 中，默认只有视图所有者或超级用户能查pg_views定义 - 如果字段必须动态计算（如权限分级显示手机号），优先考虑应用层处理，而非塞进视图——视图适合静态列裁剪，不适合复杂策略判断
角色权限链路太长时，记得检查 pg_roles / mysql.role_edges 的实际绑定
用角色管理权限很干净，但真实环境常出现“明明授了角色，用户还是查不了”的情况。根本原因往往是角色没激活，或层级嵌套断裂。PostgreSQL 中运行 SELECT rolname FROM pg_roles WHERE oid = ANY(current_user::regrole::oid[]) 可确认当前会话实际生效的角色；MySQL 8.0+ 则查 SELECT * FROM mysql.role_edges WHERE TO_HOST = '%' 看角色是否正确关联到用户。
典型陷阱：
- MySQL 中创建角色后忘记
SET DEFAULT ROLE，导致用户登录后角色不自动启用 - PostgreSQL 中角色继承关系默认关闭（
INHERIT = false），需建角色时显式写CREATE ROLE analyst INHERIT，否则即使被授予权限也不会向下传递 - 跨库视图（如 MySQL 的
db1.view_a查询db2.table_b）要求用户对两个库都有对应权限，角色无法自动跨库代理
列权限这事，表面是 SQL 写法问题，实际是权限模型、角色状态、数据库版本特性的三重叠加。哪一层松动，都可能让视图变成裸奔的窗口。
