CREATE VIEW能减少重复SQL，但仅适用于逻辑固定、无运行时变量的场景；涉及用户ID、时间范围等动态条件时，应改用参数化存储过程或应用层拼接WHERE。
CREATE VIEW 能直接减少重复 SQL，但只在逻辑固定、无运行时变量时才真正省事；一旦涉及用户 ID、时间范围、状态码等动态条件，硬套视图反而会埋坑。
视图能替代 WHERE 重复书写吗
能，但仅限于「逻辑固定」场景。比如多处用到 WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'，封装进视图后，下游只需 SELECT * FROM v_recent_users，不用再算日期。
常见错误现象：ERROR: column "start_date" does not exist——这是试图在视图定义里引用参数变量，而 PostgreSQL、MySQL 8.0 及更早版本都不支持视图传参。
- 适合封装：固定时间窗口、静态状态过滤（如
status IN ('active', 'pending')）、固定 JOIN 关系 - 不适合封装：需传入
user_id、date_from、product_category的查询 - 替代方案：这类动态逻辑应改用带
IN参数的存储过程，或应用层拼接WHERE，而非强塞进视图
多表 JOIN 视图还能被高效复用吗
能，但性能不取决于“用了视图”，而取决于底层 JOIN 是否有索引支撑。一个含 LEFT JOIN orders ON users.id = orders.user_id 的视图，如果 orders.user_id 没索引，所有查该视图的语句都会慢。
使用场景：权限类视图如 v_user_with_role 常要 JOIN users、roles、user_roles，此时必须确认 user_roles.user_id 和 user_roles.role_id 都建了索引，否则 WHERE role_name = 'admin' 会触发全表扫描。
- 建视图前先跑
EXPLAIN看原生 JOIN 的执行计划 - 避免在视图里写
SELECT *，只选下游真用的字段，减少 I/O - PostgreSQL 中复杂视图可能无法谓词下推，导致过滤条件延迟生效——用
EXPLAIN VERBOSE查扫描行数是否异常高
ALTER VIEW 会影响线上查询吗
不会锁底层数据表，但会短暂阻塞新查询启动。MySQL 中 ALTER VIEW 是纯元数据操作，只更新 mysql.schemata 和 mysql.views；PostgreSQL 中 CREATE OR REPLACE VIEW 是原子替换 pg_class/pg_rewrite 条目，已运行的查询不受影响，但正在编译的新查询会等待替换完成。
容易踩的坑：在高峰期执行 CREATE OR REPLACE VIEW，可能导致一批新请求卡顿几百毫秒——这不是锁表，而是查询编译被阻塞。
- 生产环境变更建议避开流量高峰
- 不要依赖视图名做业务逻辑分支（比如代码里写死
IF view_name == 'v_vip_orders' THEN...），视图是逻辑抽象，不是接口契约 - 命名需区分清楚，比如统一加前缀
v_，避免和真实表名冲突
视图的价值不在“加速”，而在“收敛”。它把散落在十几份脚本里的相同 JOIN+WHERE 封装成一个名字，但这个名字背后仍跑着原始 SQL——所以最常被忽略的，其实是建视图前没验证底层索引和执行计划。
