视图不支持追加WHERE条件，所有筛选必须在定义时写死或查询时显式添加；CREATE VIEW中的WHERE是语法固有部分，非可插拔模块，且无法用ALTER VIEW添加，外部WHERE与内部条件以AND叠加执行。
视图本身不支持“追加”WHERE条件，你不能在创建后给它加筛选逻辑；所有过滤必须在定义时写死，或查询时显式带上——没有中间态。
CREATE VIEW 里写 WHERE 是合法的，但不是“附加”，而是定义的一部分
视图本质是保存的 SELECT 语句，WHERE 是它语法树里的固有节点，不是后期可插拔的模块。比如：
CREATE VIEW active_users AS SELECT id, name, email FROM users WHERE status = 'active';
这不会让视图“记住”一个过滤器，而是把 WHERE status = 'active' 编译进执行计划里。后续查 SELECT * FROM active_users 就等价于跑那条带条件的 SELECT。
- 改源表数据，视图结果立刻变——它不缓存，每次重执行整条 SQL
- 不能用
ALTER VIEW ... ADD WHERE ...——语法不存在 - 如果想换条件，只能
DROP VIEW再重建，或改用参数化视图（如 PostgreSQL 的物化视图 + 查询参数，DuckDB 不支持）
查询视图时再写 WHERE，会和定义里的条件叠加（AND 关系）
外部 WHERE 不会覆盖视图内部的条件，而是与之合并。例如：
CREATE VIEW recent_orders AS SELECT order_id, user_id, amount FROM orders WHERE created_at >= '2026-01-01';
然后执行：
SELECT * FROM recent_orders WHERE amount > 1000;
实际执行等价于：
SELECT order_id, user_id, amount FROM orders WHERE created_at >= '2026-01-01' AND amount > 1000;
- 两个条件是 AND，不是 OR，也不是优先级替换
- 如果外部条件和内部冲突（如
WHERE created_at ），结果为空，数据库不报错也不警告 - 数据库优化器可能下推外部条件，也可能全扫内部结果再过滤——取决于引擎和索引，别假设一定高效
把 WHERE 放视图里 vs 放查询里，性能差别很大
看似省事的写法，往往拖慢真实查询。关键在于：视图定义的 WHERE 锁死了基础扫描范围，而外部 WHERE 可能更窄，但数据库未必能跳过视图层的冗余计算。
- 视图写
WHERE created_at >= '2025-01-01'，你却只查created_at >= '2026-07-01'→ 数据库仍可能先扫全年数据，再在外层过滤 - 索引是否生效，取决于字段是否出现在视图 SELECT 列中（比如只选
id, name，但WHERE用email，索引大概率失效） - 简单视图（无 JOIN、无子查询）+ 外部 WHERE 更易被优化；复杂视图 + 内置 WHERE 容易固化低效路径
真正需要动态过滤？别依赖视图，换别的方案
视图不是函数，它没有参数，也不能传值。如果你常要按不同 user_id、date_range 查，硬塞进视图只会让逻辑僵化。
- 用 CTE 替代：每次查询前定义一次，条件可变，还能被优化器内联
- 用预编译语句（如 Python 的
cursor.execute("SELECT ... WHERE user_id = ?", [uid])） - DuckDB/PostgreSQL 可考虑
PREPARE+EXECUTE；MySQL 8.0+ 支持存储过程封装 - 应用层拼 WHERE 字符串（注意防注入）比在视图里硬编码更灵活
最常被忽略的一点：视图的“简洁性”是假象，它掩盖了执行路径不可控的事实——你以为在复用逻辑，其实可能在重复做无用功。
