不能替代；视图仅提供逻辑隔离，不改变权限模型，用户若有基表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 + 权限回收三者绑在一起用，而不是只建一个视图就以为万事大吉。 
