视图存在连锁失效、调试困难、性能不可控、版本混乱、权限失控、脱敏失效等严重问题。它将业务逻辑绑定数据库层，缺乏测试与灰度能力，嵌套导致优化器失效，命名伪版本掩盖治理缺口，实为数据治理的“毛玻璃”。
因为视图只保存SQL逻辑，不保存数据，一旦业务规则变、表结构动、权限加、性能压，所有依赖它的查询都会连锁失效——而你根本没法像改代码那样打断点、加日志、单步调试。
视图里写CASE WHEN或复杂JOIN，等于把业务规则钉死在数据库层
比如在视图里硬编码用户等级判定：CASE WHEN total_order_amt > 10000 THEN 'VIP' ELSE 'NORMAL' END。后续等级门槛调整、新增“黄金会员”类型，就得改视图定义；BI看板、报表SQL、下游ETL脚本全得跟着验证是否受影响。更糟的是，这类逻辑通常没有单元测试，上线后才发现某类订单金额为空导致等级全为NULL。
- 修改视图 = 所有调用方隐式升级，没人知道哪些地方用了它
- 无法做灰度发布：不能只让A系统用新逻辑、B系统沿用旧逻辑
- 字段语义漂移：今天
user_level是字符串，明天要改成枚举ID，下游应用直接报错
嵌套视图超过两层，EXPLAIN输出就不可信
MySQL 8.0之前对三层嵌套视图（v_a → v_b → v_c → base_table）根本不支持WHERE条件下推；PostgreSQL虽支持，但执行计划里的cost值常严重低估真实开销。你看到rows=100，实际扫描了千万行——因为优化器压根没把外层过滤条件传进最内层。
- 查不出问题：EXPLAIN显示走索引，实际执行慢如蜗牛
- 索引失效：底层表新加了
INDEX(dt, status)，但上层视图因嵌套太深完全无法受益 - 调试黑洞：想定位哪一层拖慢了查询？得手动展开每一层SELECT，再分别EXPLAIN
视图名带时间粒度（如v_sales_2024q3），本质是用命名伪造版本控制
名字里塞v_sales_2024q3看似清晰，实则绕过真正的版本管理。季度一换，就得新建视图、改所有引用它的SQL、同步权限、清理旧视图——而物化视图或查询重写根本认不出它是“同一逻辑的不同快照”，优化器放弃下推谓词。
- BI看板SQL崩：WHERE条件写成
dt BETWEEN '2024-07-01' AND '2024-09-30'，但视图名还是v_sales_2024q2，没人敢删 - 权限失控：旧视图残留着已离职员工的访问权限，新视图还没配好ACL
- 真要快照语义？建物理表
ord_order_snapshot_v2，用INSERT INTO ... SELECT显式生成，别靠视图名糊弄自己
敏感字段脱敏放在视图里，反而掩盖真实的数据治理缺口
用CONCAT(LEFT(id_card, 3), '****', RIGHT(id_card, 4))在视图里遮掩身份证号，看起来安全，实则埋雷：下游应用可能直接取id_card字段做关联，结果关联不上；审计时发现脱敏逻辑只覆盖了视图，API接口、导出SQL、临时查询仍直连原表。
- 治理假象：以为“视图做了脱敏”就等于“数据合规”，忽略全链路管控
- 字段污染：脱敏后字段类型变成VARCHAR，原本的INT/DATE索引彻底失效
- 责任模糊：安全团队说“数据库层已处理”，开发说“我们只用视图”，没人管原始表暴露面
真正难的不是写视图，是判断哪段逻辑该留在数据库、哪段该交给应用——边界一旦划错，改起来比重写还疼。视图该是透明的玻璃窗，不是糊满胶带的毛玻璃。
