“自适应时间范围滚动”的核心逻辑是视图定义中使用current_date、now()等运行时函数配合相对偏移（如-90 day），使每次查询均基于当前时间动态计算窗口，实现伪参数化效果。
什么是“自适应时间范围滚动”的核心逻辑
它不是指视图自动改写 SQL，而是指视图定义中使用运行时可变的时间基准（比如 CURRENT_DATE、NOW()），配合相对偏移（如 -30 DAY），让每次查询都基于当前时间动态计算窗口。关键点在于：视图本身不能包含参数，但可以依赖数据库的运行时函数生成“伪参数化”效果。
PostgreSQL / MySQL 中实现滚动 90 天业务视图的写法差异
不同数据库对表达式支持程度不同，尤其在 WHERE 子句中能否直接用函数参与范围计算：
- PostgreSQL 支持直接写
WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'，且该表达式在每次查询视图时实时求值 - MySQL 8.0+ 可用
WHERE created_at >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)；但注意CURDATE()返回日期，NOW()返回带时分秒的时间戳，若字段是DATETIME类型，用NOW()更安全 - SQL Server 不支持在视图定义中直接用
GETDATE() - 90这类算术表达式（会报错“视图定义中不允许使用非确定性函数”），必须改用内联表值函数（ITVF）或应用层传参
示例（PostgreSQL）：
CREATE VIEW v_recent_orders AS SELECT order_id, customer_id, amount, created_at FROM orders WHERE created_at >= CURRENT_DATE - INTERVAL '90 days';
为什么不能在视图里用变量或参数？哪些替代方案更可靠
标准 SQL 视图不接受输入参数，所谓“参数化视图”本质是伪需求——真要传参，得靠函数、CTE 或应用层拼接。容易踩的坑：
- 误以为
CREATE VIEW v(x) AS ...能声明参数（实际语法错误） - 在视图里引用未定义的变量，如
WHERE dt > @window_start（MySQL 用户常犯，@变量只在会话级有效，视图无法捕获） - 用
SYSDATE或NOW()导致物化视图刷新失败（Oracle/MySQL 的物化视图不支持非确定性函数）
真正可落地的替代方式：
- 用内联表值函数（ITVF）：PostgreSQL 的
CREATE FUNCTION f_recent_orders(days INT) RETURNS TABLE(...)，调用时写SELECT * FROM f_recent_orders(90) - 用 CTE + 应用层注入：把
90当作参数由代码填入，生成临时 SQL 查询，而非固化在视图里 - 定时任务预生成分区表或汇总表，用
orders_2024_q2这类命名，再用视图UNION ALL最近 N 个分区（适合超大数据量）
性能隐患：滚动窗口视图为什么可能越查越慢
表面上只是加了个 WHERE 条件，但实际执行时数据库未必能高效利用索引：
- 如果
created_at字段没建索引，全表扫描不可避免 - 即使有索引，某些旧版本 MySQL 对
DATE_SUB(CURDATE(), INTERVAL N DAY)推导不出索引范围，导致索引失效（可用EXPLAIN看key_len是否为 NULL） - PostgreSQL 在统计信息过期时，可能低估滚动窗口的数据量，选错执行计划（建议定期
VACUUM ANALYZE orders） - 视图嵌套过深（如 A 视图 SELECT B 视图），会让优化器难以重写谓词下推，窗口条件可能被延迟到最外层执行
验证是否走索引的小技巧：在视图定义里先写死一个日期（如 WHERE created_at >= '2024-04-01'），执行 EXPLAIN；再换成函数形式对比输出。
滚动窗口的“动态”是便利性的代价——它把时间决策从建模阶段移交给了运行时，而数据库优化器并不总能看清你的业务意图。最稳的方式，往往是放弃“全自动”，在应用层控制窗口边界，并把视图降级为纯结构封装。
