where后面的谓词也会进入到hash 区域里？

最新推荐文章于 2025-09-28 09:28:10 发布

转载最新推荐文章于 2025-09-28 09:28:10 发布 · 84 阅读

本文深入解析了Oracle数据库中HASHJOIN操作的内部实现细节，特别是如何评估JOIN操作中表的BYTES值，通过具体示例展示了计算过程，并讨论了选择最优JOIN表的重要性。

explain plan for
select a.object_type,b.object_name,b.CREATED
from t a,t1 b
where a.object_id=b.object_id and b.STATUS=:1;

Explained.

@display

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2914261090

---------------------------------------------------------------------------
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 10157 |   515K|   132   (2)| 00:00:02 |
|* 1 | HASH JOIN         |      | 10157 |   515K|   132   (2)| 00:00:02 |
|   2 |   TABLE ACCESS FULL| T    | 20361 |   258K|    65   (0)| 00:00:01 |
|* 3 |   TABLE ACCESS FULL| T1   | 10181 |   387K|    66   (2)| 00:00:01 |
---------------------------------------------------------------------------

AVG_COL_LEN COLUMN_NAME
----------- ------------------------------
          6 OWNER
         19 OBJECT_NAME
          2 SUBOBJECT_NAME
          5 OBJECT_ID
          3 DATA_OBJECT_ID
          8 OBJECT_TYPE
          8 CREATED
          8 LAST_DDL_TIME
         20 TIMESTAMP
          7 STATUS
          2 TEMPORARY
          2 GENERATED
          2 SECONDARY
          3 NAMESPACE
          3 EDITION_NAME

看看T1表评估出来的BYTES为387K，看看这个数值是怎么计算出来的。
查询里一共出现了T1表的4个字段。分别为：object_name，CREATED，object_id，STATUS
这四个字段的长度总和结果上面的查询可以知道为：
select 39*10181/1024 from dual;

39*10181/1024
-------------
387.75293

387K，跟ORACLE计算出来的是一致的。

看来ORACLE在计算HASH 区域大小的时候，把where条件后的过滤谓词也会计算进去，这在我看来是不必的。
除非SELECT列表里需要这个字段，否则只有连接条件需要计算进去。
不过还不知道ORACLE真正在进行构建HASH区域的时候，会不会真的把这个无用字段也BUILD进去？

还有一点需要指出的，我们平时总说，HASH JOIN以小表为BUILD表比较好，准确的说法应该是以结果集的BYTES小的表为BUILD比较好。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-718065/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-718065/