普通视图每次查询都重执行全表聚合，导致报表变慢；应采用分层视图+关键字段冗余预聚合，并确保WHERE条件命中分区、GROUP BY严格合规、索引建在常用过滤/JOIN字段上。
用 CREATE VIEW 做报表视图，为什么数据一变就慢？
因为普通视图只是保存 SQL 语句，每次查都重跑全表聚合。报表场景下，SUM()、COUNT(DISTINCT)、GROUP BY 套多层，再加 JOIN 几张事实表，查询延迟直接上秒级。
真正要快，得让预聚合结果固化下来——不是靠物化视图（很多数据库不原生支持），而是靠「可维护的视图分层」+「关键字段冗余」。
- 把高频过滤字段（比如
region_id、report_month）提前算好、存进中间层视图，避免每次WHERE都扫全量 - 避免在最外层视图里写
DATE_TRUNC(created_at, MONTH)这类计算；把它挪到基础聚合层，用report_month字段暴露出来 - 如果底层表有分区（如按天分区），确保视图
WHERE条件能命中分区键，否则优化器会忽略分区剪枝
怎么设计支持多级钻取的视图结构？
钻取不是靠前端“点一下展开”，而是靠视图之间清晰的粒度嵌套：粗粒度视图只 GROUP BY 大维度，细粒度视图保留明细键但不聚合，靠 JOIN 拼接。
典型三层结构：
-
v_sales_summary_monthly：按region+product_category+report_month聚合，含total_revenue、order_count -
v_sales_detail_daily：按region+product_id+sale_date聚合，保留sku_code、channel等可下钻字段 -
v_sales_raw_joined：不聚合，只做fact_sales和dim_product、dim_store的关联，供临时探查用
关键点：所有视图的 SELECT 列名保持一致（比如都叫 region_name，不混用 region 或 region_id），否则下游 JOIN 或 BI 工具映射容易错。
GROUP BY 里漏了非聚合字段，为什么有时不报错？
MySQL 5.7 默认开启 sql_mode=ONLY_FULL_GROUP_BY，PostgreSQL 严格要求，但 SQLite 和某些 MySQL 兼容模式会静默允许——这恰恰是最危险的坑。
比如写：SELECT region, SUM(sales), product_name FROM sales GROUP BY region，product_name 值不确定，可能随机返回某一行的值，报表数字对不上却查不出错。
- 上线前务必在目标数据库上执行
SELECT @@sql_mode或等价命令，确认是否启用严格模式 - 用
EXPLAIN看执行计划，如果出现Using temporary; Using filesort，大概率是GROUP BY字段没走索引或写法触发了隐式排序 - 宁可多写几个字段进
GROUP BY，也不要依赖数据库“猜”你想要什么；BI 工具拖拽生成的 SQL 很容易踩这个坑
预聚合字段该不该加索引？加在哪一层？
视图本身不能建索引，但支撑它的底层表可以。重点不是给视图字段建索引，而是给「视图常用来 WHERE 或 JOIN 的字段」建联合索引。
例如 v_sales_summary_monthly 经常被按 region_id 和 report_month 过滤，那就在基础事实表的 sales_fact 上建：INDEX idx_region_month (region_id, report_month)。
- 别在
TEXT或JSON字段上建索引（除非用函数索引且明确需要） - 如果用了
DATE字段但查询习惯是WHERE report_month = '2024-06'，优先把report_month存成CHAR(7)或DATE并单独建索引，别总用LEFT(created_at, 7) - 定期用
pg_stat_all_indexes（PostgreSQL）或sys.dm_db_index_usage_stats（SQL Server）看索引是否真被用到，避免“建了等于没建”
复杂点在于：预聚合逻辑一旦写死在视图里，改字段就得重跑历史数据。所以第一次定义 report_month 格式、region 层级归属，就得想清楚下游所有钻取路径能不能覆盖——这里卡住，后面调半天也白搭。
