TimesTen記憶體資料庫支援雜湊、範圍和點陣圖三種型別的索引，其中雜湊索引在等值查詢中有著其他索引不能比的高效的優勢，通常用於匹配單行或多行記錄查詢。

雜湊索引的建立語法：
CREATE [UNIQUE] HASH INDEX [Owner.]IndexName ON [Owner.]TableName ({ColumnName [ASC | DESC]} [,... ] ) [ PAGES = RowPages | CURRENT ]

在建立表時指定主鍵時都會使用索引來增強對資料的掃描，預設索引範圍索引來增強主鍵查詢，然而我們也可以使用唯一雜湊來指定增強主鍵查詢；如我我們在建立主鍵時使用雜湊索引來增強主鍵查詢，那麼當應用在執行主鍵範圍掃描時，雜湊索引將會被忽略；雜湊索引在等值查詢單行或多行記錄中有著範圍索引不能比的高效的優勢。

雜湊索引在建立時，會根據雜湊索引建立時指定的PAGES引數自動分配固定數量的Buckets來儲存表的索引資訊，如果Buckets過少會降低索引雜湊度，索引雜湊度過低無論是在索引掃描、索引重建或回滾期間，均容易帶來雜湊衝突，從而帶來效能影響；PAGES引數可以透過ALTER TABLE或者先DROP TABLE後CREATETABLE的方式修改。

雜湊索引的PAGES引數在雜湊索引中如此重要，我們必須設定正確的PAGES引數來保證索引的高效使用；但是，由於應用及業務的增長，我們如何判斷我們的PAGES引數配置是否正確呢？首先，我們需要知道，TimesTen在對資料的儲存與Oracle不同，不是按照塊來儲存，而是按照頁的方式進行儲存，按照每個頁256行記錄的方式對資料進行儲存，所以PAGES＝count/256；而Bucket的計算方式為Buckets=(PAGES*256)/20。

但是，我們在實際運維中，經常會在tterrors中出現waiting for latch"Lock Hash Bucket[3918]"或者waiting for latch "Index OWNER.TABLENAME"的latch等待資訊；其實還是由於PAGES引數設定不合理引起的，主要是對count的計算不準確造成的，由於系統執行一段時間後，達標一般都會存在一定的碎片（空行），所以count=NUM_USED_ROWS+NUM_FREE_ROWS，詳細可以參考我們博文：
《如何評估和計算TimesTen記憶體資料庫表的大小》 http://blog.itpub.net/24930246/viewspace-1168811/

那麼PAGES引數是不是越大越好呢？當然不是了，PAGES引數過大，會導致Buckets過大，會佔用更多的記憶體儲存空間，記憶體對於記憶體資料庫來說是一個非常重要的指標，記憶體過大直接影響記憶體資料庫的裝載/解除安裝、恢復等消耗的時長。

－－－－－－－－－－－－－－－End－－－－－－－－－－－－－－－－－－－－－－－－－

合理配置TimesTen記憶體資料庫Hash索引的PAGES引數

相關文章