不行，SQL Server视图中禁止直接使用GETDATE()等非确定性函数作WHERE过滤，即使创建成功也会因执行计划缓存导致结果不实时；应将时间条件移至查询端或改用内联表值函数。
SQL Server里用GETDATE()在视图中做时间过滤行不行
不行，直接在视图定义里写WHERE created_at > GETDATE() - 1这类逻辑，大多数情况下会报错或被拒绝——SQL Server不允许视图中包含非确定性函数（如GETDATE()、NEWID()）作为过滤条件，除非视图加了SCHEMABINDING且函数被允许（但GETDATE()仍不被支持）。即使侥幸创建成功，查询时也可能因执行计划缓存导致结果“卡在某个时间点”，不是真动态。
真正可行的做法是把时间逻辑推到查询端：
- 视图只做数据结构封装，不带时间过滤
- 查视图时在外层
SELECT里加WHERE created_at > GETDATE() - 1 - 如果必须封装成“带过滤的视图”，改用内联表值函数（
ITVF），它支持参数和运行时函数
MySQL里用NOW()在视图中过滤为什么有时不更新
MySQL允许在视图中直接用NOW()，但要注意它的求值时机：每次查询视图时都会重新调用NOW()，看起来是动态的。问题常出在客户端或中间件开启了查询缓存（已弃用但旧配置可能残留），或者应用层对视图查询做了结果缓存。另外，如果视图用了CREATE ALGORITHM=TEMPTABLE，部分版本下NOW()可能在临时表构建阶段就被固化一次，后续行过滤失效。
稳妥做法：
- 显式指定
ALGORITHM=MERGE（默认，推荐）：CREATE ALGORITHM=MERGE VIEW recent_orders AS SELECT * FROM orders WHERE order_time > NOW() - INTERVAL 1 DAY;
- 避免在视图里用
SYSDATE()（它受事务起始时间影响，非实时） - 确认MySQL版本 ≥ 5.7，低版本对视图中函数的支持边界更模糊
跨数据库兼容写法：如何让视图既支持SQL Server又支持MySQL
没有纯SQL标准的“跨库动态时间函数”能直接塞进视图定义里。CURRENT_TIMESTAMP是SQL标准函数，在两者中都可用且行为接近（SQL Server中等价于GETDATE()，MySQL中等价于NOW()），但它依然受限于前述的非确定性限制——SQL Server仍禁止在视图WHERE中直接使用。
所以兼容方案本质是放弃“视图内置过滤”，转向接口层统一处理：
- 视图定义统一用占位符注释，比如
-- @filter: last_24h，作为团队约定 - 所有调用方必须补上
WHERE created_at > CURRENT_TIMESTAMP - INTERVAL '1' DAY（PostgreSQL/Oracle）或WHERE created_at > DATEADD(day, -1, GETDATE())（SQL Server） - 如果用ORM，把时间条件抽成方法，如
RecentOrders().Last24Hours()，底层按方言生成对应SQL
为什么不能用存储过程替代视图来实现动态时间过滤
可以，但目的不同：存储过程返回结果集，不具视图的“可组合性”。你无法在JOIN里直接引用存储过程，也不能把它当表名嵌套在复杂查询中（除非用OPENROWSET之类非常规手段，代价高且不安全）。而视图的核心价值是抽象+复用+可组合。
真要动态时间+可组合，优先选内联表值函数（SQL Server）或物化视图（PostgreSQL 9.3+，MySQL不支持）：
- SQL Server示例：
CREATE FUNCTION dbo.RecentOrders(@hours INT) RETURNS TABLE AS RETURN (SELECT * FROM orders WHERE order_time > DATEADD(hour, -@hours, GETDATE()));
调用：SELECT * FROM dbo.RecentOrders(24) - 注意：ITVF不支持
GETDATE()以外的非确定性函数，且不能有副作用 - 函数体必须是单个
SELECT，不能含变量赋值或控制流
动态时间过滤这件事，关键不在函数名选NOW还是GETDATE，而在于你是否混淆了“定义时求值”和“执行时求值”——视图是前者，查询是后者。多数翻车，都是试图让视图替你记住“此刻”这个概念。
