BI连物化视图变慢主因是BI自动添加SELECT *、ORDER BY或表达式转换，导致优化器无法命中物化视图而回退扫描基表；需确保SQL纯净、字段类型一致、物化视图建有匹配索引并刷新统计信息。
BI工具连物化视图时，为什么查得比原表还慢
不是物化视图本身变慢了，而是BI工具发出来的SQL被“二次加工”了，导致数据库没法直接读取物化视图的物理存储，反而绕回去扫基表。最常见的情况是：BI自动加了SELECT *、隐式ORDER BY、或对字段做了表达式转换（比如UPPER(name)），触发优化器放弃物化视图访问路径。
BI生成的SQL里出现ORDER BY或LIMIT就危险
很多BI工具（如旧版DataEase、部分帆软模板）在渲染前会默认加ORDER BY字段（哪怕你没配排序）或LIMIT 1000防爆屏。一旦物化视图定义里不含对应排序字段，或者没建好索引，数据库就无法用物化视图的物理顺序快速截取，只能全量扫描+排序+裁剪——这时执行计划里会出现Using filesort或Materialize节点，速度直接打回原形。
- 检查BI最终下发的SQL：打开日志或抓包，确认是否含未声明的
ORDER BY、LIMIT、DISTINCT - 物化视图若用于BI，必须显式包含常用排序字段，并在该字段上建索引（例如
CREATE INDEX idx_mv_sales_dt ON mv_sales_monthly (sales_month DESC)） - 禁用BI的“自动排序”开关（如有），或在数据集配置里明确写死
ORDER BY字段，确保与物化视图索引顺序一致
字段类型不匹配让BI跳过物化视图
BI工具解析物化视图元数据时，如果字段类型识别错（比如把DECIMAL(18,2)当成字符串），后续过滤、聚合、排序都会失效，有些BI甚至因此放弃查询重写（Query Rewrite），转而下推到基表执行原始逻辑。Oracle中DBA_MVIEWS.STALENESS = 'FRESH'只代表数据同步完成，不代表类型元数据已刷新。
- 用
DESCRIBE或\d mv_name（PG）检查物化视图字段类型，和BI连接后看到的列类型是否一致 - 避免在物化视图定义里用
CAST或函数包裹关键过滤字段（如CAST(order_date AS DATE)），改用基表原生类型+计算列 - Oracle用户注意：
DBMS_STATS.GATHER_TABLE_STATS必须对物化视图名执行，且cascade => TRUE，否则统计信息缺失会导致类型推断失败
物化视图没索引，等于白建
物化视图是张“表”，不是“视图”。它不自带索引，也不继承基表索引。BI查它时走全表扫描，和查一张没索引的普通表毫无区别。尤其当BI带WHERE tenant_id = ? AND status = 'active'这种组合条件时，没有覆盖索引，性能立刻崩盘。
- 为物化视图单独建索引，字段顺序严格按BI高频WHERE条件排列（例如
(tenant_id, status)，不能反过来） - PostgreSQL用
CONCURRENTLY刷新时，必须先有唯一索引，否则报错；MySQL 8.0+需确保物化视图ALGORITHM = MERGE，否则索引无效 - 别依赖“基表有索引所以物化视图也能用”——执行计划里看
OBJECT_NAME列，确认访问的是物化视图名，不是基表名
