數據庫中的熱點問題

---

熱點是應用中常見的問題之一。在系統并發量比較小的時候，通常感覺不到它的存在，而當并發請求急劇增加的時候，響應時間被大大地拉長，極端情況系統掛起。

熱點可能在記錄上，可能在數據或索引頁面上，也可能在其它對象上，比如緩沖池、程序包，甚至到數據庫之下的操作系統層。常見的是前兩種。

典型的記錄熱點場景有：應用維護流水號，或者余額控制，相關信息保存在用戶表的記錄中，每次交易都作UPDATE操作。UPDATE會在記錄上加獨占鎖，會堵塞其它應用對同一條記錄的UPDATE操作，這個獨占鎖要等整個事務提交或回滾后才會釋放。假設這個事務執行時間是10毫秒，那么這個系統能支撐的最大交易吞吐量是100筆/秒，更多的交易請求進來將處于等待狀態。

如何能夠知道系統存在這種熱點問題？ 如果做數據庫監測的話，可關注并發應用數、應用等鎖次數和平均鎖等待時間，

如果等鎖次數及等待時間隨應用并發增加而增加的話，很有可能存在這種問題。

也有可能你的系統負載一直不高，看不到上述變化，又怎么能知道系統有這種風險？

在DB2中可用命令db2pd –db -tcbstats獲取表相關的操作信息，在“TCB Table Stats:”段內容中有表上發生UPDATE的次數，用次數除以表的記錄數，可計算出平均每行記錄被更新的次數，如果某表上這個指標較高，意味著可能有熱點記錄問題。當然這個辦法不一定很準確，比如表中有很多條記錄，其中一條或幾條被更新的次數遠高于其它，便不能用這種方法識別出來，更準確的方法是捕捉到每一條SQL語句，分析UPDATE操作指向的記錄。 預先知道隱含問題，就可以改進系統，避免出現類似“雙十一”或“秒殺”活動對系統帶來的沖擊。

改進方法就是去除熱點或分散熱點。比如可用數據庫的SEQUENCE幫助產生流水號，數據庫的SEQUENCE可在內存一次產生多個流水號，個數由CACHE指定，并發高的系統可加大CACHE；分散熱點是將一條記錄拆成多條記錄，根據傳入參數更新對應記錄。

除記錄熱點外，還有可能出現數據頁面或索引頁面熱點。比如多條記錄保存在同一個數據頁面，雖然并發應用更新的是不同記錄，但數據庫內部在更新數據頁面內容時會加LATCH以避免內容錯亂，用一般的數據庫監控可能不能發現此類問題，使用db2pd -latch有可能看到沖突。解決辦法是減少同一個數據頁面內保存的記錄數，比如(ALTERTABLE myTable PCTFREE 90; REORG TABLE myTable)，重組之后每個頁面只用10%的空間保存記錄。當然你也可能有其它方法達到此目的。

索引頁面的熱點主要發生在索引字段內容一直增加或減少的情況，比如時間戳或流水號上的索引，每次INSERT進來的記錄，其相關索引內容都落在最后的索引頁面中，這在單服務器的數據庫中可能沒太大問題，但在集群環境中，這個熱點問題會被放大。DB2中有一種RANDOM INDEX可規避這個問題，比如：CREATEINDEX myIdx ON myTable (seqno RANDOM)；RANDOMINDEX是基于變換后的內容構建索引，因此它失去了原來的順序，避免了索引頁面熱點，但只適合“=”條件查詢，BETWEEN及“>”之類查詢條件不能從這種索引中得到原來的好處。

如果能在設計開發階段就考慮到些熱點問題，避開它，就更好了。

如果您碰到其它一些熱點問題，也可以拿出來跟大家分享一下。

慧都控件網年終促銷第一波已開啟，全場6折起，豪禮搶不停>>>

截止時間：2016年10月30日

詳情請咨詢！

客服熱線：023-66090381