mysql效能調優與架構設計(一)商業需求與系統架構對效能的影響

標籤：

這裡我們就拿一個看上去很簡單的功能來分析一下。

需求：一個論壇文章總量的統計
附加要求：即時更新

在很多人看來，這個功能非常容易實現，不就是執行一條SELECT COUNT(*)的Query 就可以得到結果
了嗎？是的，確實只需要如此簡單的一個Query 就可以得到結果。但是，如果我們採用不是MyISAM 儲存
引擎，而是使用的Innodb 的儲存引擎，那麼大家可以試想一下，如果存放文章的表中已經有上千萬的帖
子的時候，執行這條Query 語句需要多少成本？恐怕再好的硬體裝置，恐怕都不可能在10 秒之內完成一
次查詢吧。如果我們的訪問量再大一點，還有人覺得這是一件簡單的事情嗎？
既然這樣查詢不行，那我們是不是該專門為這個功能建一個表，就只有一個欄位，一條記錄，就存
放這個統計量，每次有新的文章產生的時候，都將這個值增加1，這樣我們每次都只需要查詢這個表就可
以得到結果了，這個效率肯定能夠滿足要求了。確實，查詢效率肯定能夠滿足要求，可是如果我們的系
統文章產生很快，在高峰時期可能每秒就有幾十甚至上百個文章新增操作的時候，恐怕這個統計表又要
成為大家的噩夢了。要麼因為並發的問題造成統計結果的不準確，要麼因為鎖資源爭用嚴重造成整體性
能的大幅度下降。
其實這裡問題的焦點不應該是實現這個功能的技術細節，而是在於這個功能的附加要求“即時更
新”上面。當一個論壇的貼文量很大了之後，到底有多少人會關注這個統計資料是否是即時變化的？
有多少人在乎這個資料在短時間內的不精確性？我想恐怕不會有人會傻傻的盯著這個統計數字並追究當
自己發了一個文章然後回頭重新整理頁面發現這個統計數字沒有加1 吧？即使明明白白的告訴使用者這個統計
資料是每過多長時間段更新一次，那有怎樣？難道會有很多使用者就此很不爽嗎？
只要去掉了這個“即時更新”的附加條件，我們就可以非常容易的實現這個功能了。就像之前所提
到的那樣，通過建立一個統計表，然後通過一個定時任務每隔一定時間段去更新一次裡面的統計值，這
樣既可以解決統計值查詢的效率問題，又可以保證不影響新發貼的效率，一舉兩得。
實際上，在我們應用的系統中還有很多很多類似的功能點可以最佳化。如某些場合的列表頁面參與列
表的資料量達到一個數量級之後，完全可以不用準確的顯示這個列表總共有多少條資訊，總共分了多少
頁，而只需要一個大概的估計值或者一個時間段之前的統計值。這樣就省略了我們的分頁程式需要在分
以前即時COUNT 出滿足條件的記錄數。
其實，在很多應用系統中，即時和准即時，精確與基本準確，在很多地方所帶來的效能消耗可能是
幾個效能的差別。在系統效能最佳化中，應該盡量分析出那些可以不即時和不完全精確的地方，作出一些
相應的調整，可能會給大家帶來意想不到的巨大效能提升。

無用功能堆積使系統過度複雜影響整體效能

很多時候，為系統增加某個功能可能並不需要花費太多的成本，而要想將一個已經運行了一段時間
的功能從原有系統中撤下來卻是非常困難的。
首先，對於開發部門，可能要重新整理很多的代碼，找出可能存在與增加該功能所編寫的代碼有交
集的其他功能點，刪除沒有關聯的代碼，修改有關聯的代碼；
其次，對於測試部門，由於功能的變動，必須要迴歸測試所有相關的功能點是否正常。可能由於界
定困難，不得不將迴歸範圍擴充到很大，測試工作量也很大。
最後，所有與撤除下線某個功能相關的工作參與者來說，又無法帶來任何實質性的收益，而恰恰相
反是，帶來的只可能是風險。
由於上面的這幾個因素，可能很少有公司能夠有很完善的項目（或者功能）下線機制，也很少有公
司能做到及時將系統中某些不合適的功能下線。所以，我們所面對的應用系統可能總是越來越複雜，越
來越龐大，短期內的複雜可能並無太大問題，但是隨著時間的積累，我們所面對的系統就會變得極其臃
腫。不僅維護困難，效能也會越來越差。尤其是有些並不合理的功能，在設計之初或者是剛上線的時候
由於資料量較小，帶來不了多少效能損耗。可隨著時間的推移，資料庫中的資料量越來越大，資料檢索
越來越困難，對真箇系統帶來的資源消耗也就越來越大。
而且，由於系統複雜度的不斷增加，給後續其他功能的開發帶來實現的複雜度，可能很多本來很簡
單的功能，因為系統的複雜而不得不增加很多的邏輯判斷，造成系統應用程式的計算量不斷增加，本身
效能就會受到影響。而如果這些邏輯判斷還需要與資料庫互動通過持久化的資料來完成的話，所帶來的
效能損失就更大，對整個系統的效能影響也就更大了。

 

我們資料庫中存放的資料都是適合在資料庫中存放的嗎？

對於有些開發人員來說，資料庫就是一個操作最方便的萬能儲存中心，希望什麼資料都存放在資料
庫中，不論是需要持久化的資料，還是臨時存放的過程資料，不論是普通的純文字格式的字元資料，還
是多媒體的位元據，都喜歡全部塞如資料庫中。因為對於應用伺服器來說，資料庫很多時候都是一
個集中式的儲存環境，不像應用伺服器那樣可能有很多台；而且資料庫有專門的DBA 去幫忙維護，而不
像應用伺服器很多時候還需要開發人員去做一些維護；還有一點很關鍵的就是資料庫的操作非常簡單統
一，不像檔案操作或者其他類型的儲存方式那麼複雜。

實際上，以下幾類資料都是不適合在資料庫中存放的：

1. 二進位多媒體資料
將二進位多媒體資料存放在資料庫中，一個問題是資料庫空間資源耗用非常嚴重，另一個問題
是這些資料的儲存很消耗資料庫主機的CPU 資源。這種資料主要包括圖片，音頻、視頻和其他一些
相關的二進位檔案。這些資料的處理本不是資料的優勢，如果我們硬要將他們塞入資料庫，肯定會
造成資料庫的處理資源消耗嚴重。

2. 流水隊列資料
我們都知道，資料庫為了保證事務的安全性（支援事務的儲存引擎）以及可恢複性，都是需要
記錄所有變更的日誌資訊的。而流水隊列資料的用途就決定了存放這種資料的表中的資料會不斷的
被INSERT，UPDATE 和DELETE，而每一個操作都會產生與之對應的日誌資訊。在MySQL 中，如果是支
持事務的儲存引擎，這個日誌的產生量更是要翻倍。而如果我們通過一些成熟的第三方隊列軟體來
實現這個Queue 資料的處理功能，效能將會成倍的提升。

3. 超大文本資料
對於5.0.3 之前的MySQL 版本，VARCHAR 類型的資料最長只能存放255 個位元組，如果需要儲存更
長的文本資料到一個欄位，我們就必須使用TEXT 類型（最大可存放64KB）的欄位，甚至是更大的
LONGTEXT 類型（最大4GB）。而TEXT 類型資料的處理效能要遠比VARCHAR 類型資料的處理效能低下
很多。從5.0.3 版本開始，VARCHAR 類型的最大長度被調整到64KB 了，但是當實際資料小於255
Bytes 的時候，實際儲存空間和實際的資料長度一樣，可一旦長度超過255 Bytes 之後，所佔用的存
儲空間就是實際資料長度的兩倍。
所以，超大文本資料存放在資料庫中不僅會帶來效能低下的問題，還會帶來空間佔用的浪費問
題。

mysql效能調優與架構設計(一)商業需求與系統架構對效能的影響