SQL 优化 第七章 查询转换 2视图合并和谓词推入

参考资料：
本系列博客主要参考资料有CUUG冉乃纲老师数据库教学笔记，《SQL优化核心思想》（罗炳森，黄超，钟侥著），《PostgreSQL技术内幕：查询优化深度探索》（张树杰著），排名不分先后。

 

2视图合并和谓词推入

2.1视图合并

2.1.1 视图合并环境准备

create table tests1 as select * from dba_objects;

create table tests2 as select * from dba_objects;

create index ix_tests1_id on tests1(object_id);

create index ix_tests2_id on tests2(object_id);

2.1.2 视图合并定义及产生原因

视图合并，就是连接的对象中有视图，或者内联视图时，不是等视图把结果运行出来，再进行连接，而是直接和视图内的表进行连接。执行计划的直接表现就是该出现VIEW的地方没有VIEW，并且连接顺序可能会被彻底打乱。

视图展开根据不同场景，对性能可能有益，也可能有害。

表面看，视图合并打乱连接顺序，很多场景下还可能降低执行计划的阅读性，那优化器为什么还要产生视图合并呢？

如果视图不合并，那么连接的对象就是视图检索出来的结果集，不能走索引，这样，在最优执行计划的选择上会有有害影响；

然而，视图合并后，连接的对象变成了表，可以利用索引，连接方式的选择上也更加灵活。

2.1.3 有害的视图合并

这个是在做半连接和内连接的转换章节时偶尔运行出来的有害的视图合并，本来希望内联视图内去重复后，再连接，以减少连接返回数据量，但是，视图内的表直接连接后，因为数据倾斜原因，返回数据量超级大，导致性能问题。具体参考<半连接和内连接转换>专题。

至于这个有害视图合并产生的原因，我个人猜测是优化器为了减少去重复运算的次数，

我们的本意是做三次去重复，内联视图A B和最后的结果每次都去重复，但是优化器想在最后一次去重复，这里，我还的替数据库强大的优化器说句好话，并不是优化器不智能，而是优化器产生执行计划的基础，统计信息过期造成的，我们收集统计信息后，优化器也就纠正了这个性能低的执行计划。

SELECT DISTINCT A.OWNER

FROM (SELECT DISTINCT OWNER FROM TESTS1) A,

      (SELECT DISTINCT OWNER FROM TESTS2) B

WHERE A.OWNER=B.OWNER;<