标准SQL视图不支持运行时参数，需用CURRENT_DATE等函数实现相对时间过滤，或通过应用层封装函数传入具体时间范围来复用审计表查询逻辑。
为什么直接查审计表总要写重复的 WHERE created_at BETWEEN ? AND ?
审计日志表（比如 audit_log）通常字段多、数据量大，且每次查询几乎都带时间范围过滤。硬编码或反复拼接 created_at BETWEEN '2024-01-01' AND '2024-01-31' 容易出错，也难以复用。视图本身不存储数据，但能固化常用过滤逻辑——把时间范围判断下推到视图定义里，后续查询就只需关注业务维度。
如何创建带参数化时间范围的视图（PostgreSQL / MySQL 8.0+）
严格来说，标准 SQL 视图不支持运行时参数。但可通过以下方式模拟“参数化”效果：
- 定义视图时用占位函数（如 PostgreSQL 的
current_date、now()），配合相对时间计算，例如只查最近 7 天：CREATE VIEW recent_audit AS SELECT * FROM audit_log WHERE created_at >= CURRENT_DATE - INTERVAL '7 days';
- 若需任意范围，推荐用**物化视图（PG）或生成列+索引（MySQL）辅助**，但更通用的做法是：建一个基础视图去掉敏感字段、统一时间字段类型，并强制加上
created_at IS NOT NULL条件避免索引失效 - 关键点：在视图中显式写出
created_at >= ? AND created_at 是无效的——问号不会被解析，必须靠外部查询再套一层
真正可复用的方案：视图 + 应用层封装函数
把视图当作“预过滤基表”，实际查询仍由应用代码驱动。例如 Python 中封装一个查询函数：
def query_audit_by_range(start_dt: str, end_dt: str):
return db.execute(
"SELECT * FROM audit_view WHERE created_at >= ? AND created_at < ?",
[start_dt, end_dt]
)对应视图定义只需做三件事：
- 精简字段（去掉
raw_payload等大文本，除非必查） - 确保
created_at有索引，且类型为TIMESTAMP WITH TIME ZONE（PG）或DATETIME（MySQL），避免隐式转换 - 加
WHERE created_at IS NOT NULL，防止优化器跳过索引
容易忽略的坑：时区、边界和索引失效
审计日志最常翻车的不是逻辑，而是时间处理细节：
-
BETWEEN '2024-01-01' AND '2024-01-31'会漏掉 31 日 23:59:59.999 后的数据——改用>= start AND 更安全 - 数据库时区 ≠ 应用时区 ≠ 日志采集时区。视图里别用
CURRENT_TIMESTAMP做绝对过滤，除非确认全链路统一为 UTC - 如果
created_at是TEXT类型（某些老系统导出日志），视图里用TO_TIMESTAMP(created_at, 'YYYY-MM-DD HH24:MI:SS')转换后无法走索引——必须提前在源表加函数索引或修正字段类型
视图省不了动态条件，但它能锁死字段投影、统一格式、暴露清晰接口。真正省事的是别让每个开发都重新想一遍怎么写时间过滤。
