首页 / MYSQL / 哈希连接(hashjoin)原理

哈希连接(hashjoin)原理

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了哈希连接(hashjoin)原理，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6788字，纯文字阅读大概需要10分钟。

内容图文

哈希连接(hash join)原理哈希连接(hashjoin) 访问次数：驱动表和被驱动表都只会访问0次或1次。驱动表是否有顺序：有。是否要排序：否。应用场景： 1. 一个大表，一个小表的关联； 2. 表上没有索引； 3. 返回结果集比较大。原理我们说的简单一点，先把驱

哈希连接(hash join)原理

哈希连接(hashjoin)

访问次数：驱动表和被驱动表都只会访问0次或1次。

驱动表是否有顺序：有。

是否要排序：否。

应用场景： 1. 一个大表，一个小表的关联；

2. 表上没有索引；

3. 返回结果集比较大。

原理我们说的简单一点，先把驱动表的关联字段hash到PGA中（当然rowid也在PGA中），然后扫描被驱动表，取第一条数据，将关联的字段hash 一下探测PGA中的小表，如果匹配则关联，再取第二条........。

下面我们来做个试验：

SQL> create table test1 as select * from dba_objects where rownum <=100;
SQL> create table test2 as select * from dba_objects where rownum <=1000;
SQL> exec dbms_stats.gather_table_stats(user,'test1');
SQL> exec dbms_stats.gather_table_stats(user,'test2');
SQL> alter session set statistics_level=all;

SQL> select /*+leading(t1) use_hash(t2)*/count(*)
      from test1 t1, test2 t2
     where t1.object_id = t2.object_id;
  COUNT(*)
----------
       100

SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  3f2mts0kt82u2, child number 0
-------------------------------------
select /*+leading(t1) use_hash(t2)*/count(*)   from test1 t1, test2 t2  where t1.object_id = t2.object_id
Plan hash value: 2544416891

----解释一下：

Starts为该sql执行的次数。

E-Rows为执行计划预计的行数。

A-Rows为实际返回的行数。A-Rows跟E-Rows做比较，就可以确定哪一步执行计划出了问题。

A-Time为每一步实际执行的时间（HH：MM：SS.FF），根据这一行可以知道该sql耗时在了哪个地方。

Buffers为每一步实际执行的逻辑读或一致性读。

Reads为物理读。

OMem、1Mem为执行所需的内存评估值，0Mem为最优执行模式所需内存的评估值，1Mem为one-pass模式所需内存的评估值。

0/1/M 为最优/one-pass/multipass执行的次数。

Used-Mem耗的内存

------------------------------------------------------------------------------------------------------------------
| Id  | Operation           | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE     |       |      1 |      1 |      1 |00:00:00.01 |      19 |       |       |          |
|*  2 |   HASH JOIN         |       |      1 |    100 |    100 |00:00:00.01 |      19 |  1066K|  1066K| 1162K (0)|
|   3 |    TABLE ACCESS FULL| TEST1 |      1|    100 |    100 |00:00:00.01 |       4 |       |       |          |
|   4 |    TABLE ACCESS FULL| TEST2 |      1 |   1000 |   1000 |00:00:00.01 |      15 |       |       |          |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")


SQL> select /*+leading(t1) use_hash (t2)*/count(*)
      from test1 t1, test2 t2
     where t1.object_id = t2.object_id
       and t1.object_id = 99999;
  COUNT(*)
----------
         0


SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  f9zwsrs05kg0n, child number 0
-------------------------------------
select /*+leading(t1) use_hash (t2)*/count(*)   from test1 t1, test2 t2  where t1.object_id =
t2.object_id    and t1.object_id = 99999
Plan hash value: 2544416891
------------------------------------------------------------------------------------------------------------------
| Id  | Operation           | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE     |       |      1 |      1 |      1 |00:00:00.01 |       4 |       |       |          |
|*  2 |   HASH JOIN         |       |      1 |      1 |      0 |00:00:00.01 |       4 |   921K|   921K|  176K (0)|
|*  3 |    TABLE ACCESS FULL| TEST1 |      1 |      1 |      0 |00:00:00.01 |       4 |       |       |          |
|*  4 |    TABLE ACCESS FULL| TEST2 |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
   3 - filter("T1"."OBJECT_ID"=99999)
   4 - filter("T2"."OBJECT_ID"=99999)

SQL> select /*+leading(t1) use_hash (t2)*/count(*)
  2    from test1 t1, test2 t2
  3   where t1.object_id = t2.object_id
  4     and 1=2;
  COUNT(*)
----------
         0
SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  bnrfbt4ybxnnp, child number 0
-------------------------------------
select /*+leading(t1) use_hash (t2)*/count(*)   from test1 t1, test2 t2  where t1.object_id =
t2.object_id    and 1=2
Plan hash value: 1013001923
---------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name  | Starts | E-Rows | A-Rows |   A-Time   |  OMem |  1Mem | Used-Mem |
---------------------------------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE      |       |      1 |      1 |      1 |00:00:00.01 |       |       |       |
|*  2 |   FILTER             |       |      1 |        |      0 |00:00:00.01 |       |       |       |
|*  3 |    HASH JOIN         |       |      0 |    100 |      0 |00:00:00.01 |   921K|   921K|       |
|   4 |     TABLE ACCESS FULL| TEST1 |      0 |    100 |      0 |00:00:00.01 |       |       |       |
|   5 |     TABLE ACCESS FULL| TEST2 |      0 |   1000 |      0 |00:00:00.01 |       |       |       |
---------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter(NULL IS NOT NULL)
   3 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")

内容总结

以上是互联网集市为您收集整理的哈希连接(hashjoin)原理全部内容，希望文章能够帮你解决哈希连接(hashjoin)原理所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/531689.html

来源：【匿名】

【上一篇】MySQLCluster安装与配置【下一篇】用IE远程创建Mysql数据库的简易程序

更多 ►

【哈希连接(hashjoin)原理】教程文章相关的互联网学习教程文章

Mysql 自定义HASH索引带来的巨大性能提升----[真相篇]【图】

推倒重来俗话说no zuo no die why you try,这时候我又忍不住zuo了，吭哧吭哧的把解决过程发上博客，向全世界宣布，哥又搞定个难题。剧情的发展往往是看起来主角完全掌握了局势的情况下，会突然跳出来一个很牛的反面人物，然后搞得主角很惨，搞的过程中主角开始小宇宙爆发，然后逆袭。这次也不例外。踢场子的人该出现了一顿狂侃之后，发现我原来牛逼的分析，完全经不起推敲。几个问题1）在未做HASH索引之前，为什么大表的ROWS那么...

MySQL hash分区（四）【图】

详细描述总结请看MySQL分区（一）例子：该例子为本人个人学习总结分享->详细说明-->有问题欢迎前来交流原文：http://blog.csdn.net/leyangjun/article/details/38233571

InnoDB的关键特性-插入缓存,两次写,自适应hash索引详解【图】

InnoDB存储引擎的关键特性包括插入缓冲、两次写（double write）、自适应哈希索引（adaptive hash index）。这些特性为InnoDB存储引擎带来了更好的性能和更高的可靠性。插入缓冲插入缓冲是InnoDB存储引擎关键特性中最令人激动的。不过，这个名字可能会让人认为插入缓冲是缓冲池中的一个部分。其实不然，InnoDB缓冲池中有Insert Buffer信息固然不错，但是Insert Buffer和数据页一样，也是物理页的一个组成部分。主键是行唯一的标...

Redis数据类型之HASH类型

Redis hash 是一个 string 类型的 field 和 value 的映射表.它的添加、删除操作都是 O(1) （平均）。 hash 特别适合用于存储对 HASH类型-特点 Redis hash 是一个 string 类型的 field 和 value 的映射表.它的添加、删除操作都是 O(1) （平均）。 hash 特别适合用于存储对象。相较于将对象的每个字段存成单个 string 类型。将一个对象存储在 hash 类型中会占用更少的内存，并且可以更方便的存取整个对象。省内存的原因是新建一...

MySQL的btree索引和hash索引的区别

ash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来...

mysql之Innodb特性adaptive hash index【代码】

If a table fits almost entirely in main memory, the fastest way to perform queries on it is to use hash indexes. InnoDB has a mechanism that monitors index searches made to the indexes defined for a table. If InnoDB notices that queries could benefit from building a hash index, it does so automatically. The hash index is always built based on an existing B-tree index on the table. InnoDB can build...

MySQL索引类型 btree索引和hash索引的区别

Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来...

MySQL-Comparison of B-Tree and Hash Indexes

PRIMARY KEY, UNIQUE, INDEX, and FULLTEXT) are stored in B-trees. Exceptions: Indexes on spatial data types use R-trees; MEMORY tables also support hash indexes; InnoDBuses inverted lists for FULLTEXT indexes. 没多少内容，直接看原文吧 http://dev.mysql.com/doc/refman/5.7/en/index-btree-hash.html 、只要使用了Limit mysql 会尽力使用索引、 MySQL-Comparison of B-Tree and Hash Indexes标签：本文系统来...

MySQL的btree索引和hash索引的区别【图】

。可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。（1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基...

MySQL的btree索引和hash索引&聚集索引【图】

这样就可以理解为什么innodb的主键索引不能用离散的数据。下图为2层btree结构： 2，哈希索引建立在哈希表的基础上，它对每个值采用精确查找。每一行都需要先计算哈希码，比较好的哈希算法算出比较低的重复的度，这样效率相对高一些。如果算出来的值是一样的，那么它需要再进行判断哪个值才是想要的值，所以说在表里面采用哈希索引，但是重复度又比较高，那么哈希索引效率就比较低。 HASH索引PK BTREE索引：大量不同数据等值...

MySQL hash分区（四）【图】

具体描写叙述总结请看MySQL分区（一）样例：该样例为本人个人学习总结分享->具体说明-->有问题欢迎前来交流MySQL hash分区（四）标签：water ack 技术分享 img net data .net ext hash 本文系统来源：http://www.cnblogs.com/liguangsunls/p/7222194.html

nginx+PHP+memcached+MySQL+ip-hash做memcached集群【代码】

1、nginx与memcached整合#安装memcached支持的事务库libeventwget https://github.com/libevent/libevent/releases/download/release-2.0.22-stable/libevent-2.0.22-stable.tar.gz tar zxf libevent-2.0.22-stable.tar.gz cd libevent-2.0.22-stable ./configure --prefix=/usr/local/libevent make && make install echo $? cd ..#接下来安装memcached:wget http://www.memcached.org/files/memcached-1.4.35.tar.gz tar zxf me...

MySQL Hash索引和B-Tree索引的区别

MySQL Hash索引和B-Tree索引的区别究竟在哪里呢？相信很多人都有这样的疑问，下文对两者的区别进行了详细的分析，供您参考。 MySQL Hash索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而...

MySQL-如何删除hash表分区【代码】

一个大表，之前是以hash分区表的形式存在的，MySQL> show create table history_uint;| history_uint | CREATE TABLE `history_uint` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT ‘0‘, `value` bigint(20) unsigned NOT NULL DEFAULT ‘0‘, `ns` int(11) NOT NULL DEFAULT ‘0‘, PRIMARY KEY (`itemid`,`clock`,`ns`), KEY `i_clock` (`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 /*!5010...

MySQL的btree索引和hash索引的区别

MySQL的btree索引和hash索引的区别ash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是...

首页 / MYSQL / 哈希连接(hashjoin)原理

哈希连接(hashjoin)原理

内容导读

内容图文

内容总结

内容备注

内容手机端

【哈希连接(hashjoin)原理】教程文章相关的互联网学习教程文章

哈希 - 相关标签

MYSQL - 技术教程分类

MYSQL - 最新教程

MYSQL - 最热教程