有没有发现，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
----------
347650915410g以后，他们的关系是这样的：
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的意义所在。