不能替代；视图仅提供逻辑隔离，不改变权限模型，用户若有基表SELECT权限即可绕过，必须配合权限回收（REVOKE基表权限+GRANT视图权限）才能实现基本行级控制。

视图能否替代行级安全策略（RLS）？

不能直接替代，但可作为轻量级替代方案。SQL Server 的原生 ROW LEVEL SECURITY（RLS）需创建安全策略函数并绑定到表，而视图仅靠 WHERE 和列投影实现逻辑隔离——它不改变底层权限模型，也不参与执行计划的谓词下推优化。如果用户有基表 SELECT 权限，仍可能绕过视图直接查表；因此视图必须配合权限回收：先 REVOKE SELECT ON dbo.employees FROM user1，再只授视图权限。

如何用视图同时限制行和列？

在 CREATE VIEW 中嵌入 WHERE 过滤 + 显式列列表即可。关键点是避免使用 *，且过滤条件要基于可稳定获取的上下文（如 SUSER_NAME()、SESSION_CONTEXT() 或连接表中的角色字段）。

• 示例：销售员只能看到自己部门的活跃客户，且仅暴露 name、email、region

• CREATE VIEW sales_customer_view AS
  SELECT c.name, c.email, c.region
  FROM customers c
  INNER JOIN departments d ON c.dept_id = d.id
  WHERE d.manager_login = SUSER_NAME()
    AND c.status = 'active';

• 若需支持多角色（如区域经理看多个 region），可改用 SESSION_CONTEXT(N'region')，并在应用层提前设置：EXEC sp_set_session_context @key = N'region', @value = 'North';
• 注意：视图中不能用 IS_MEMBER('sales_team') 做行过滤——该函数在视图定义时求值，不是每次查询时动态执行

为什么不能对视图加 UPDATE / INSERT？

SQL Server 对可更新视图有严格限制：只要视图包含 JOIN、GROUP BY、聚合函数、子查询或非确定性函数（如 GETDATE()），就默认不可更新。即使简单单表视图，也需确保：

• SELECT 列全部来自单一基表，不含计算列或常量
• 未使用 DISTINCT、TOP、UNION
• 基表主键或唯一索引列必须全部包含在视图 SELECT 列中（否则 SQL Server 无法定位被修改的行）
• 若必须支持写操作，优先考虑 INSTEAD OF 触发器，而非依赖自动可更新性

视图权限与基表权限的叠加关系

SQL Server 不会自动继承基表权限。授予用户对视图的 SELECT 权限，不代表他能访问视图所引用的基表——但如果他已有基表权限，就能绕过视图直接查表。所以生产环境必须显式回收：

• REVOKE SELECT ON dbo.customers FROM [user1];
• GRANT SELECT ON sales_customer_view TO [user1];
• 若视图引用多个表，需逐个回收对应基表权限；遗漏任一表，都可能导致数据泄露
• 注意：VIEW DEFINITION 权限会暴露视图 SQL，含敏感过滤逻辑，一般不应授予普通用户

视图实现细粒度控制最易被忽略的一点：它完全依赖“权限隔离”的完整性。一旦某人意外获得基表 SELECT 权限，整个视图封装就形同虚设。真正可靠的方案，是把视图 + RLS + 权限回收三者绑在一起用，而不是只建一个视图就以为万事大吉。