视图定义中可包含WHERE条件，但它是查询逻辑的一部分而非附加属性，不能通过ALTER VIEW添加；查询视图时外部WHERE会与定义中的条件叠加执行，且视图不缓存数据、每次重执行底层SQL。
视图定义里不能直接写WHERE条件
视图本身是保存的查询逻辑，不是真实表，所以你在 CREATE VIEW 语句里不能像普通查询那样在末尾加 WHERE 来“固化”筛选结果。比如下面这种写法是错的：
CREATE VIEW active_users AS SELECT id, name, status FROM users WHERE status = 'active'; -- ✅ 这语法合法，但注意：它只是定义视图逻辑，并非“锁定”数据
真正容易误解的是：有人以为这样定义后，后续查这个视图就永远只看到 status = 'active' 的行——其实没错，但这不是因为视图“自带WHERE”，而是因为它的底层查询本身就写了那个条件。一旦你改了源表数据，视图结果立刻跟着变。
- 视图本质是“预存的 SELECT 语句”，
WHERE是它的一部分，不是附加属性 - 不能对已创建的视图用
ALTER VIEW ... ADD WHERE ...——没有这种语法 - 如果想动态筛选，必须在查询视图时再加
WHERE，而不是指望视图自己“记住”条件
查询视图时加WHERE才真正生效
你查视图时写的 WHERE，会和视图定义里的条件“叠加”或“合并”，最终由数据库优化器决定怎么执行。比如：
CREATE VIEW user_summary AS SELECT id, name, department, salary FROM employees;
然后执行：
SELECT * FROM user_summary WHERE department = 'Tech' AND salary > 8000;
这等价于：
SELECT id, name, department, salary FROM employees WHERE department = 'Tech' AND salary > 8000;
关键点：
- 视图不缓存数据，每次查询都重跑底层 SQL
- 如果你在视图定义里已经写了
WHERE department = 'Tech'，再在外面加WHERE salary > 8000，两个条件会一起生效（AND 关系） - 但如果外面加的是
WHERE department = 'HR'，而视图里限定死了department = 'Tech'，结果就是空集——数据库不会报错，只会返回 0 行
WHERE放在视图里 vs 放在外面：性能差异明显
把筛选条件写进视图定义，看似省事，实则可能拖慢查询。原因在于：数据库无法提前知道你后续会不会加更严格的条件，只能按视图定义全量执行基础查询。
- 比如视图定义为
SELECT * FROM logs WHERE created_at >= '2025-01-01'，但你实际只想查created_at >= '2026-07-01'——数据库仍会先扫一遍 2025 年全年的数据，再在外层过滤 - 相反，如果视图是宽泛定义（如只选字段、无 WHERE），你每次查时加精确条件，优化器更容易利用索引（尤其是
created_at上的索引） - 某些数据库（如 PostgreSQL）支持“条件化视图”或物化视图，但标准 SQL 视图不自动下推谓词（predicate pushdown），别依赖它帮你优化
NULL 值和类型隐式转换会让 WHERE 在视图里更难调试
视图字段类型来自底层查询，如果原始列允许 NULL，而你在视图定义里用了函数（比如 COALESCE(name, 'unknown')），再在外面加 WHERE name = 'unknown' 就可能不匹配——因为视图里的 name 已经不是原始列了。
-
WHERE中的列名，始终指代视图输出的列，不是源表列；同名列可能含义不同 - 字符串比较要注意大小写和空格：视图若用了
UPPER(name)，外面就不能写WHERE name = 'alice'，得写WHERE name = 'ALICE' - 日期字段如果在视图里被格式化成字符串（如
DATE_FORMAT(created_at, '%Y-%m')），你就不能再用BETWEEN做范围比较，只能用LIKE或字符串函数
最麻烦的是错误不报在 CREATE VIEW 阶段，而是在你第一次 SELECT 它时才暴露——比如类型不匹配导致隐式转换失败，或者 NULL 参与比较永远为 false。
