最近在将一个11g的数据库导入到12c（12.1.0.2，并打了最新的补丁）的库后，测试人员反馈有一个SQL执行结果不正确。
具体的SQL如下：

SELECT *
FROM ( SELECT watnum,
agentcode,
managecom,
SUM (prem) AS prem,
SUM (charge) AS charge
FROM (SELECT ct.card_number,
ct.card_managecode,
cp.riskcode,
cp.riskname,
cp.prem,
csm.watnum,
csm.charge,
SUBSTR (csm.agentcode, 2) AS agentcode,
SUBSTR (csm.managecom, 2) AS managecom
FROM card_table@webapp ct,
ZZHCardSettleMent csm,
CARDPREMIUM@WEBAPP cp
WHERE ct.card_type = cp.cardtype
AND csm.idcard = ct.card_number
AND csm.checktype = 1
AND ct.card_managecode = '8602')
GROUP BY watnum, agentcode, managecom) c
WHERE NOT EXISTS
(SELECT 'Y'
FROM policyinfo
WHERE c.watnum = proposalcontno);

由于第一个子查询（我们姑且把它称为C子查询）涉及到DBLINK，所以一开始怀疑DBLINK不一致导致的。但是查看了DBLINK的配置后发现和源11g的配置是一样的，连的都是相同的数据库。

试着单独C子查询，在11g和12c中的执行结果是一样的！

接着试着把C子查询的结果做成一张表ctemp，用ctemp代替C子查询，即：

SELECT *
FROM ctemp c
WHERE NOT EXISTS
(SELECT 'Y'
FROM policyinfo
WHERE c.watnum = proposalcontno);

这时在11g和12c中的执行结果是一样的。

接着试着把C子查询的结果做成一张试图cvtemp，用cvtemp代替C子查询，即：

SELECT *
FROM cvtemp c
WHERE NOT EXISTS
(SELECT 'Y'
FROM policyinfo
WHERE c.watnum = proposalcontno);

查询的结果出现差异了。仔细观察执行计划，似乎12c中的执行计划有异常，NOT EXISTS这个条件居然没有在执行计划中体现！因为这是在用视图的情况下发生的，所以有理由怀疑12c的优化器在视图合并上是有异常的，那把视图合并禁用掉会是什么情况？

SELECT /*+ NO_MERGE(c) */ *
FROM cvtemp c
WHERE NOT EXISTS
(SELECT 'Y'
FROM policyinfo
WHERE c.watnum = proposalcontno);

这里通过HINT禁用了视图合并，执行结果和11g是一样的了。然后观察执行计划，非常明显的在禁用了视图合并后多了NOT EXISTS条件的过滤：
filter( NOT EXISTS (SELECT 0 FROM "POLICYINFO" "POLICYINFO" WHERE "PROPOSALCONTNO"=:B1))
而在之前的执行计划中是没有这个过滤的。

考虑到C子查询是个复杂视图，所以尝试在系统层面禁用了复杂视图的合并：

alter system set "_complex_view_merging"=false;

再执行上述语句时，即使不加HINT也能执行出正确的结果了。

简单视图合并会不会也存在上述类似的问题？这个还有待验证。

12c引入了很多吸引人的功能，比如对租户，比如内存数据库，还有更强大的优化器。但是首要保证的是执行出正确的结果，如果这都无法保证了，那一切都要成为浮云了。

Oracle Database 12c查询优化器的缺陷-视图合并会造成查询结果不准确