SQL Server视图中禁用GETDATE()等非确定性函数，因其导致索引失效、执行计划错误缓存；应改用参数化内联表值函数或由调用方传入日期参数。
SQL Server 里用 GETDATE() 做动态日期范围为什么总出错
直接在视图定义里写 WHERE order_date >= GETDATE() - 30 看似合理，但 SQL Server 会把它当成“确定性函数”处理，而 GETDATE() 是非确定性的——这会导致视图无法被索引（哪怕你加了 SCHEMABINDING），也容易在某些执行计划中被错误缓存。更麻烦的是，有些 BI 工具或链接服务器查询时会把这类视图当静态对象预编译，结果日期逻辑就失效了。
真正能落地的做法是：视图只封装结构，不固化时间逻辑；把动态部分交给调用方传参，或改用内联表值函数（ITVF）替代视图。
- 别在视图里直接调用
GETDATE()、SYSDATETIME()或DATEADD()这类运行时函数 - 如果必须用视图，把日期条件抽象成参数占位符，例如用
@start_date和@end_date，再配合应用层或存储过程传入 - 更推荐方案：改写为内联表值函数，例如
ufn_orders_by_date_range(@start_date DATE, @end_date DATE)，它支持参数、可复用、执行计划也更稳定
PostgreSQL 视图里怎么安全用 CURRENT_DATE
PostgreSQL 对非确定性函数比 SQL Server 宽松，CURRENT_DATE、NOW() 可以直接出现在视图定义中，且不会阻止 CREATE MATERIALIZED VIEW（物化视图）的创建——但前提是别混用窗口函数或子查询中的相关变量。
不过要注意：物化视图刷新时，CURRENT_DATE 是取刷新时刻的值，不是查询时刻；普通视图每次查才计算，所以行为一致。容易踩的坑是误以为物化视图里的 CURRENT_DATE 会“自动更新”。
- 普通视图用
CURRENT_DATE - INTERVAL '7 days'安全，每次查询都重算 - 物化视图若依赖动态日期，必须定期手动
REFRESH MATERIALIZED VIEW，否则数据就“冻住”了 - 避免在
WHERE中对日期字段用函数，例如WHERE DATE(created_at) = CURRENT_DATE，会跳过索引；应写成created_at >= CURRENT_DATE AND created_at
MySQL 视图中用 NOW() 的兼容性陷阱
MySQL 5.7+ 允许在视图中使用 NOW()、CURDATE()，但有个硬限制：不能在启用了 sql_mode=STRICT_TRANS_TABLES 且视图含子查询时嵌套调用，会报错 ERROR 1356: View references invalid table(s) or column(s)。根本原因是 MySQL 在解析视图元数据阶段就尝试预估函数返回类型，而 NOW() 的精度（datetime vs timestamp）可能引发歧义。
绕过方法很简单：统一用 CURDATE()（只返回日期部分）或显式转类型，同时确保视图定义里没有多层嵌套子查询。
- 安全写法：
WHERE order_date >= CURDATE() - INTERVAL 30 DAY - 危险写法：
WHERE DATE(order_date) = DATE(NOW())（索引失效 + 多余计算） - 如果要用小时级动态范围，改用
CAST(NOW() AS DATETIME)显式声明类型，避免隐式转换冲突
跨数据库统一处理动态日期的务实建议
没有银弹。不同数据库对“运行时值”的容忍度差异太大，硬要在视图里塞动态逻辑，后期维护成本远高于收益。实际项目中最省心的做法，是把日期范围控制权交还给应用层或调度系统。
- 视图只保留核心 join 和过滤骨架，例如
WHERE order_date BETWEEN @start AND @end，具体值由调用方绑定 - BI 工具（如 Power BI、Tableau）通常支持参数化查询，直接传入日期参数比改视图更灵活
- 定时任务场景下，用存储过程生成临时表或分区表，比反复查带
GETDATE()的视图性能好得多
最常被忽略的一点：开发时用固定日期测试（如 '2024-01-01'）没问题，但上线后没人检查视图是否真在用“当前”逻辑——建议在视图注释里明确写上“此视图不含动态日期逻辑，需外部传参”，避免接手的人掉坑。
