场景:
通常遇到涉及多个表的复杂sql查询时,我们会习惯性地建个视图,基于视图再做过滤查询。这比较容易带来性能问题,跟简单视图不同的是,在复杂视图查询的背后,数据库会自动地物化一个视图,即创建一个包含视图数据的临时表,基于这个临时表再执行查询,并在查询完成后删除临时表。
结果:
如果数据库工作量中包含许多要求视图物化的查询,那么总的DBMS吞吐量将会急剧下降。
如果数据库中数据修改发生的概率低于或远远低于数据查询,可以通过创建物化视图提高查询效率,但是:物化视图的相关源表的数据更新会带来另外的物化视图“更新效率”的问题,物化视图可以选择实时的更新或定时从事务日志应用更改,无论采取何种方式,更新视图的源表相比普通数据库表,效率都要低得多。
所以:
针对数据库中更新操作与查询操作频繁度对比,选择性地建立物化视图可以优化性能。一般情况下,尽量不在sql中使用复杂视图进行查询。
通常遇到涉及多个表的复杂sql查询时,我们会习惯性地建个视图,基于视图再做过滤查询。这比较容易带来性能问题,跟简单视图不同的是,在复杂视图查询的背后,数据库会自动地物化一个视图,即创建一个包含视图数据的临时表,基于这个临时表再执行查询,并在查询完成后删除临时表。
结果:
如果数据库工作量中包含许多要求视图物化的查询,那么总的DBMS吞吐量将会急剧下降。
如果数据库中数据修改发生的概率低于或远远低于数据查询,可以通过创建物化视图提高查询效率,但是:物化视图的相关源表的数据更新会带来另外的物化视图“更新效率”的问题,物化视图可以选择实时的更新或定时从事务日志应用更改,无论采取何种方式,更新视图的源表相比普通数据库表,效率都要低得多。
所以:
针对数据库中更新操作与查询操作频繁度对比,选择性地建立物化视图可以优化性能。一般情况下,尽量不在sql中使用复杂视图进行查询。