《怪异的SQL执行计划》的评论 http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/ Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务 Sun, 11 Jan 2015 04:43:00 +0000 hourly 1 https://wordpress.org/?v=5.3.18 作者：敬勇 http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/#comment-1479 Sun, 11 Jan 2015 04:43:00 +0000 http://www.killdb.com/?p=2417#comment-1479 可能在10g中如果先访问INDSMALL1索引作为驱动结果集，再过次object_id列上的索引访问BIG1表，是通过object_id列上的索引只能执行单块读取，这样计算出来的成本还不如先全表扫描BIG1表，让它作为驱动结果集。而在11g中对于嵌套循环在通过索引访问被驱动表时使用了向量I/O,在先访问INDSMALL1索引作为驱动结果集，再通过索引访问表BIG1时，就可以使用向量I/O。但这只是我的猜测，当在11g将版本降低为10g相同的版本后，执行结果与10g中一致。

]]> 作者：敬勇 http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/#comment-1478 Sun, 11 Jan 2015 04:32:00 +0000 http://www.killdb.com/?p=2417#comment-1478 11g中嵌套循环在通过索引访问被驱动表时使用了向量I/O，从你的11g的执行计划中可以看到两次
NESTED LOOPS,而在10g中只有一次NESTED LOOPS.我测试的结果是当在11g中指定/*+ optimizer_features_enable(‘10.2.0.5’) */ Hint后，11g中的执行结果与10g中是一样的。

]]> 作者：carcase http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/#comment-1467 Thu, 23 Oct 2014 09:32:00 +0000 http://www.killdb.com/?p=2417#comment-1467 你的sql是不是写错了

SELECT t.*
FROM BIG1 T
WHERE T.OBJECT_ID IN
(SELECT T1.OBJECT_ID FROM SMALL1 T1 WHERE T1.OWNER = ‘SYS’)

]]> 作者：ssaer http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/#comment-1466 Wed, 22 Oct 2014 02:21:00 +0000 http://www.killdb.com/?p=2417#comment-1466 10g下本来就应该是走semi的. 那样的执行计划是正确的.
11g下应该是优化了算法或者说优化了半连接..

]]> 作者：roger http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/#comment-1465 Tue, 21 Oct 2014 15:15:00 +0000 http://www.killdb.com/?p=2417#comment-1465 11g这里只是对比下，不是重点，你看我最后的测试，都是在10g测试的呀？

]]> 作者：ssaer http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/#comment-1464 Tue, 21 Oct 2014 03:35:00 +0000 http://www.killdb.com/?p=2417#comment-1464 你偷换了一个概念.把自己弄糊涂了.
在11g中,转换前后的SQL是不等价的.11g中采用了SORT UNIQUE避免了不等价.

]]> 作者：roger http://www.killdb.com/2014/10/20/%e6%80%aa%e5%bc%82%e7%9a%84sql%e6%89%a7%e8%a1%8c%e8%ae%a1%e5%88%92/#comment-1463 Mon, 20 Oct 2014 13:49:00 +0000 http://www.killdb.com/?p=2417#comment-1463 10.2.0.4 ,windows 7 x64测试如下：

SQL> select * from table(dbms_xplan.display_cursor(NULL,NULL,'ALLSTATS'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------
------------------------------------------------------------
SQL_ID 744z7fvx3unrc, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ t.* FROM BIG1 T WHERE T.OBJECT_ID IN(SELECT
T1.OBJECT_ID FROM SMALL1 T1 WHERE T.OWNER='SYS')

Plan hash value: 3425505090

------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------------
|* 1 | FILTER | | 2 | | 12 |00:00:00.02 | 47640 |
| 2 | TABLE ACCESS FULL| BIG1 | 2 | 50330 | 100K|00:00:00.01 | 1396 |
|* 3 | FILTER | | 100K| | 12 |00:00:00.10 | 46244 |
|* 4 | INDEX RANGE SCAN| INDSMALL1 | 46244 | 1 | 12 |00:00:00.08 | 46244 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter( IS NOT NULL)
3 - filter(:B1='SYS')
4 - access("T1"."OBJECT_ID"=:B1)

]]>