SQL Server 视图中禁止直接使用GETDATE()过滤，因其为非确定性函数；正确做法是视图不带时间条件，外层查询添加DATEADD(day,-1,GETDATE())，或改用支持参数的内联表值函数。
SQL Server 视图里不能直接用 GETDATE() 做时间过滤
直接在视图定义中写 WHERE created_at > GETDATE() - 1 会失败，SQL Server 明确禁止在视图中使用非确定性函数（如 GETDATE()、NEWID()）作为过滤条件。即使绕过语法检查侥幸创建成功，查询结果也大概率被执行计划缓存“钉住”，实际时间不会更新。
真正可行的做法是把时间逻辑移出视图：
- 视图只保留基础字段和关联，不带任何时间 WHERE 条件
- 调用时在外层加过滤：
SELECT * FROM myview WHERE created_at > DATEADD(day, -1, GETDATE()) - 若需封装逻辑，改用内联表值函数（ITVF），它支持参数且可被优化器展开，例如：
CREATE FUNCTION dbo.fn_recent_orders(@days INT)
MySQL 视图中用 NOW() 看似动态，但有隐藏陷阱
NOW() 在 MySQL 视图中允许使用，每次查询确实会重新求值，但问题常出在底层机制上：
- 如果视图用了
ALGORITHM=TEMPTABLE，NOW()可能在临时表构建阶段就被固化一次，后续行过滤失效 - 旧版本 MySQL（
- 客户端或中间件开启了已弃用的查询缓存，导致结果不刷新
稳妥写法是显式指定 ALGORITHM=MERGE（默认值），并避免用 SYSDATE()——它受事务起始时间影响，不是实时的。
想让视图支持参数？别硬塞，用 ITVF 或应用层补条件
视图本身不接受参数，WHERE status = @p_status 这类写法必然报错 Must declare the scalar variable "@p_status"，这不是配置或权限问题，而是 SQL 标准限制。
替代方案很明确：
- SQL Server：用内联表值函数（ITVF），如
dbo.fn_orders_by_status('shipped')，它能参与 JOIN、WHERE 下推，性能接近视图 - PostgreSQL：配合
LATERAL使用表值函数 - MySQL：用 CTE 或命名子查询折中，或直接在应用层拼接条件
- 所有场景下，都不要在函数体里调用
GETDATE()或NOW()，否则无法被索引视图引用
动态权限过滤必须靠 SESSION_CONTEXT，不是 USER_NAME()
USER_NAME() 只能识别登录账号，没法表达“当前操作属于哪个租户/部门”。真正可用的是 SESSION_CONTEXT——由应用层主动设置，比如 sp_set_session_context 'tenant_id', 123。
视图里引用时必须防错：
- 未设上下文时
SESSION_CONTEXT(N'tenant_id')返回NULL，直接CAST会报错 - 正确写法是：
tenant_id = ISNULL(CAST(SESSION_CONTEXT(N'tenant_id') AS INT), -1) - 连接复用时务必重置上下文，否则残留值会导致越权或漏查
跨数据库兼容基本不存在——CURRENT_TIMESTAMP 虽然两边都支持，但 SQL Server 仍禁止在视图 WHERE 中直接使用，最终还得靠接口层统一补条件。
