视图中硬写where条件会将业务规则固化，破坏其作为虚拟表的通用性。正确做法是仅封装结构稳定逻辑（如字段裁剪、计算列、多表关联），动态过滤应由调用方通过外部where、参数化函数或行级安全实现。
视图里写WHERE等于把业务规则焊死在定义里
视图本该是“虚拟表”，语义上应尽可能贴近基表——字段一致、行语义完整、无业务裁剪。一旦在CREATE VIEW里硬加WHERE created_at >= '2024-01-01'，它就不再是原始数据的逻辑投影，而变成一张带固定时间快照的只读快照表。
下游查询无法绕开这个条件：哪怕只是临时查一笔历史订单做对账，SELECT * FROM orders_view WHERE id = 12345也查不到——因为视图展开后实际执行的是SELECT ... FROM orders WHERE created_at >= '2024-01-01' AND id = 12345，逻辑上已排除所有旧数据。
- 修改视图需DBA权限+上线审批，紧急排查时根本来不及
- 多个业务线共用同一视图时，A部门要查近3个月，B部门要查近6个月，只能建多个视图（
orders_view_q1、orders_view_halfyear），维护成本指数级上升 - 测试环境与生产环境时间范围不一致，视图定义无法复用，必须人工改写
WHERE合并可能引发语义冲突或优化器误判
视图内WHERE status = 'active'和外部查询WHERE status = 'inactive'同时出现，不是“后者覆盖前者”，而是产生不可满足谓词（unsatisfiable predicate）。某些 PostgreSQL 版本会直接报错或返回空结果集，MySQL 则可能静默跳过整个执行路径，导致数据丢失但无提示。
更隐蔽的问题是性能：假设视图定义含WHERE level IN ('ERROR', 'WARN')，外部再加WHERE timestamp > '2025-01-01'，若底层表没建(level, timestamp)复合索引，优化器可能放弃索引，全表扫描后再逐行判断两个条件。
- 视图展开后，优化器不一定能把外部
WHERE下推到基表扫描阶段，尤其当视图含JOIN或DISTINCT时 - 聚合类视图（如
GROUP BY user_id）加外部WHERE，过滤发生在聚合后，语义已变——你本想筛原始订单，结果却在筛用户汇总值 - MySQL 5.7 对视图展开较激进，容易把条件隔离在子查询层，导致索引失效
真正该由视图承担的过滤类型只有三类
视图适合封装**结构不变、语义稳定、无上下文依赖**的逻辑。时间范围、租户ID、状态码这类动态值，都不该出现在视图定义中。
-
字段裁剪：隐藏敏感列，如
CREATE VIEW user_public AS SELECT id, name, email FROM users -
计算列封装：把复杂表达式收口，如
total_amount = qty * unit_price + tax -
多表关联整合：把常用
JOIN固化，如user_order_summary视图预联users和orders
所有带参数的过滤，都应该交给调用方：应用层拼WHERE、函数传参、或用行级安全（RLS）按登录角色动态生效。视图只管“怎么组织数据”，不管“要哪部分数据”。
DATE_TRUNC不是过滤手段，别把它当WHERE用
DATE_TRUNC('month', order_time)本身不筛数据，它只是把时间归一化成月初日期，方便后续做范围比较或分组。有人误写成WHERE DATE_TRUNC('month', order_time) = DATE_TRUNC('month', NOW())塞进视图，这仍是硬编码——只不过把字符串换成了函数调用，本质没变。
真正该做的，是在查询视图时才用它：
SELECT * FROM orders_view
WHERE order_time >= DATE_TRUNC('month', NOW());
这样既避免视图固化时间逻辑，又利用了order_time字段本身的索引（前提是没在它上面套函数）。
硬编码过滤最麻烦的地方不在实现难度，而在它让视图从“可组合的基础构件”退化成“一次性的定制快照”——下次需求变，你就得重来一遍，而不是改一行WHERE。
