有没有发现，v$session,v$sql,v$sqlarea,v$sqltext,v$sql_shared_cursor等试图连接的时候经常会用到hash_value,sql_id，但是他们2个之间到底有什么不可告人的关系呢？

Talnel以及评论的一坨人（包括jonathan）给了一个蛮不错的解释：

SQL_ID is just a fancy representation of hash value

sys@TESTDB>select kglnahsv, kglnahsh from x$kglob where kglnaobj ='select ''landrover'' from dual';

KGLNAHSV                            KGLNAHSH
--------------------------------- ----------
8605074c682c4c4da7d495aacf3751e2  3476509154
8605074c682c4c4da7d495aacf3751e2  3476509154

sys@TESTDB>select sql_id, hash_value, old_hash_value from v$sql where sql_text ='select ''landrover'' from dual';

SQL_ID        HASH_VALUE OLD_HASH_VALUE
------------- ---------- --------------
agp4ppb7mfng2 3476509154     3053997704

同时，10g+提供了一个sql_id到hash_value转换的方法：

sys@TESTDB>select dbms_utility.SQLID_TO_SQLHASH('agp4ppb7mfng2') hash_value FROM DUAL;

HASH_VALUE
----------
3476509154

10g以后，他们的关系是这样的：

1)oracle 用MD5算法对library cache obj 进行哈希，生成一个128bit的hash value，也就是KGLNAHSV(16进制).

2)KGLNAHSV的低64bit作为SQL_ID(32进制).

3)KGLNAHSV的低32bit作为HASH_VALUE(10进制)

因为10g+的哈希算法变了，所以10g之前的hash_value其实v$sql.old_hash_value。

但是需要说的是，library cache obj实际上还是通过hash_value+address的方式来组织的，Tanel只说了sql_id的后4 bytes是hash_value，但是没有说前4 bytes代表什么含义，个人觉得KGLNAHSV中有一部分应该是代表了address的，因为既然hash_value是sql_id的子集，如果sql_id可以唯一确定一个obj，那单独用hash_value肯定会存在不同SQL_ID但HASH_VALUE冲突的情况，尽管目前没人遇到过或者证明过，以他得话来说，可能性是1 in 4 billion。

至于oracle推出SQL_ID的意义，Tanel认为只是hash_value的一个更友好的别名。按照jonathan的说法，以后的版本可能会逐渐淘汰4 bytes的HASH_VALUE，而改用8 bytes的SQL_ID（也许名字会不一样），因为他更精确。但是现有的代码很多地方都还使用的32-bit的hash_value，所以hash_value需要做到向后兼容，就像当初10g逐渐淘汰9i的哈希算法一样(v$sql.old_hash_value)。这可能就是sql_id的意义所在。

具体计算可以参考：
关于sql_id与hash_value
Oracle sql_id and hash value

转自： http://www.johnnydb.com/2012/03/sql_id-vs-hash_value/