宽表不能直接用视图“瘦身”，因为视图不减少物理I/O，必须先删除高成本字段（JSON/TEXT/XML、冗余计算字段、历史快照字段），再用视图做逻辑隔离；轻量视图应避免WHERE过滤、未索引JOIN、无下推能力的计算字段，并依赖基础表的覆盖索引优化。
宽表为什么不能直接用视图“瘦身”？
视图本身不存储数据，它只是保存 SQL 查询逻辑。如果你把一张 50 列、含大量冗余字段（比如重复的用户地址、多级分类路径、JSON 扩展字段）的宽表 orders_full 直接封装成 CREATE VIEW v_orders_light AS SELECT id, user_id, amount, status FROM orders_full，那确实看起来“轻”了——但底层执行时，数据库仍要全量读取原表所有列（尤其当原表有 LOB、TEXT 或未索引的大字段），I/O 和内存开销一点没少。
真正降低存储压力的前提是：**先删掉宽表里不该存的数据，再用视图做逻辑隔离**。视图不是减肥药，而是手术后的绷带。
哪些字段必须从宽表物理删除？
重点盯三类高成本字段：
-
jsonb/TEXT/XML类型字段：它们不参与查询过滤或聚合，仅用于下游系统解析（如日志快照、埋点原始数据）——这类应迁出到归档表或对象存储，原表只留metadata_hash或log_id外键 - 派生字段（
full_name,category_path,is_vip_flag）：若计算逻辑稳定且高频使用，应改用生成列（PostgreSQL 12+ 支持STORED生成列）或物化视图；若低频，则彻底删除，由视图按需计算 - 历史快照字段（
user_name_at_order_time,price_at_order_time）：这类本质是时间切片冗余，应拆成独立order_snapshots表，主表只保留当前有效引用
视图怎么写才能避免拖慢查询？
轻量视图的核心是「查什么，取什么」，不是「取出来再筛」。常见陷阱：
- 在视图里写
WHERE status IN ('paid', 'shipped')—— 这会让所有调用该视图的 SQL 都强制走这个过滤，丧失灵活性。正确做法是去掉 WHERE，让上层决定是否加条件 - 用
LEFT JOIN关联用户表取user_name，但没给users.id加索引 → 每次查视图都触发全表扫描。必须确保所有 JOIN 字段已建索引 - 视图里包含
CASE WHEN计算字段（如discount_type），但底层字段无索引 → 无法下推谓词。如果该字段常被WHERE或GROUP BY使用，宁可建函数索引：CREATE INDEX idx_orders_discount_type ON orders ((CASE WHEN discount > 0 THEN 'coupon' ELSE 'none' END))
示例：一个安全的轻量视图定义
CREATE VIEW v_orders AS SELECT o.id, o.user_id, o.amount, o.status, o.created_at, -- 不做 JOIN，用外键代替关联字段，由应用层或上层 JOIN 控制 o.user_id AS _user_ref FROM orders o -- 不加 WHERE，不限定时间范围 -- 不 SELECT json_detail、raw_log 等大字段
MySQL / PostgreSQL 在轻量视图上的关键差异
同一份视图 SQL，在不同引擎表现可能天差地别：
- MySQL 8.0+ 支持
ALGORITHM = MERGE（默认），意味着视图会被内联展开，能利用底层索引；但一旦视图含子查询、聚合、DISTINCT，就会退化为TEMPTABLE，强制物化中间结果 → 查询变慢、内存暴涨 - PostgreSQL 的视图始终是 MERGE 式展开，无 TEMPTABLE 模式，但要注意：如果视图用了
LATERAL或窗口函数，且上层查询又加了LIMIT，优化器可能无法下推 LIMIT，导致全量计算后再截断 - 两者都不支持对视图直接
CREATE INDEX。想加速视图查询，唯一靠谱方式是：在视图所依赖的基础表上建好覆盖索引，例如视图只查(user_id, status, created_at)，那就建复合索引CREATE INDEX idx_orders_usc ON orders (user_id, status, created_at)
真正省存储的发力点永远在基础表结构上——视图只是让这张“瘦下来”的表更易用、更难误用。很多人卡在“以为建了视图就万事大吉”，结果发现慢查询日志里全是视图名，而底层宽表还在默默膨胀。
