數據庫的使用你可能忽略了這些 (續)

前言

以前寫過一篇文章《數據庫的使用你可能忽略了這些》，主要是從一些你們使用使用時容易忽略的地方，如：字段長度、表設計等來講明，這篇文章一樣也是這樣的主題，只是從另外的幾個方面來講說數據庫使用中，容易忽略，致使入坑的地方。

合理預估數據量

在數據庫進行表設計的時候，就應該評估可能產生的數據量，數據量會對整個開發和代碼的健壯性有很大的影響。開發一個數據量萬級別、十萬級別、百萬級別、千萬以上級別數量的應用，在開發思路、技術選型、架構都能都要很大的差異。
基本上的個人原則是：

• 萬級別的數據庫，能夠隨意一點，SQL編寫有好的習慣；
• 十萬級別，注意索引，注意聯表性能；
• 百萬級別，儘可能減小聯表，儘可能不要作彙總查詢，如查總數 ；
• 千萬以上級別，除緩存以外，使用分表分庫 ；

不少系統由於在設計表的時候，沒有很好的預估的後期系統的發展，致使上線不久就出現沒法支撐的狀況，代碼上太多的聯表查詢，不在意基礎的SQL性能，致使數據庫的瓶頸很快就顯現出來，不得不重構系統。設計數據庫的時候，必定是基於業務進行設計的，對業務的發展有必定的預估，看得長遠一點。

合理預估併發訪問量

數據庫有自然的瓶頸，就是併發量。咱們通常會經過緩存來減小數據庫的併發鏈接，以及對數據庫的操做，數據庫的併發，不是隻有大型平臺纔會遇到，不少中小平臺其實也會面臨這樣的問題，例如：

循環進行數據庫的操做

這個問題，上一篇文章我也提到過，不要在循環裏進行數據庫的操做，這個會直接致使數據庫鏈接數暴增，影響很是嚴重。雖然是個比較低級的問題，可是出現的機率實際上是很是高的，在我身邊看到不少不少這種案例了，這種問題，就是須要程序員本身自己避免這些問題，固然，也能夠經過一些手段去監控，找到這些問題，只是會比較麻煩一點。

業務自己的高頻次數據請求

其實有些業務，即便是中小型的平臺，也會有高併發請求數據庫的狀況，常見的例子如：日誌。例如，咱們須要抓取到全部人的操做日誌，或者全部模塊的加載時間，而且持久化保存。若是，當初選型經過Mysql去記錄這些數據，那麼就很容易遇到高併發的問題。這種就是屬於選型的錯誤了。

數據庫對高併發的處理一直是短板，因此應該儘可能避免高併發的數據庫操做，查詢經過緩存處理，增刪改這能夠經過MQ或者Kafka這樣的工具異步進行處理，若是對數據庫的結構化要求不高，則能夠用hbase或者hive進行數據庫的保存。

數據庫線程池的合理使用

如今數據庫的操做都是使用線程池的，線程池主要是用來控制數據庫的鏈接數，其實鏈接池是不屬於數據庫範疇，可是，通常咱們使用和數據庫結合很是緊密，因此在這裏一併說明。
通常線程池都會有這樣的幾個參數：

參數	說明
最小鏈接數	不論是否有數據庫的操做，這幾個鏈接都會一直存在，
最大鏈接數	容許的最大的鏈接數，若是超過了這個數據，則沒法申請鏈接，只能等待，或者異常
回收時間	多長時間會對全部的鏈接進行一次斷開，而後從新鏈接。
釋放時間	多長時間沒有進行操做的鏈接，會釋放

基本全部的鏈接池都會有這幾個參數，可能不一樣的鏈接池參數名不一樣，可是做用是同樣的。 這裏咱們重點說一下最大鏈接數，這個是很容易忽略的一個設置。
不少人設置最大鏈接數的時候，喜歡設置的很大，例如設置爲5000，可是通常mysql的數據庫一個實例鏈接默認才1000，鏈接數超過這個了數據庫也沒法處理，設置的再大實際上是沒用的。

服務器數量 * 最大鏈接數 < 數據庫最大鏈接數

並且，這仍是在一個實例，一個數據庫的狀況下，至於多個數據庫：
我建議

服務器數量 * 最大鏈接數 * 數據庫數量 < 數據庫最大鏈接數

若是單個數據庫佔用了太多的數據庫鏈接，會影響到其餘數據庫，致使其餘數據庫也沒法使用。
固然，這個值你們能夠根據業務去進行合理的估算，高頻的業務分配多一點，低頻的業務分配少一點。不要盲目的一味設置鏈接池的最大值。

總結

現在，雖然各類各樣的存儲方式出現，可是關係數據庫一直是咱們系統的最重要的組成部分，儘可能不要過早暴露數據庫應對併發的短板，設計數據庫和操做數據庫在咱們的開發中應該是一件很神聖的事情，認證對待關係的數據庫的每個操做纔是明智之舉。

擴展閱讀：
數據庫的使用你可能忽略了這些
學會數據庫讀寫分離、分表分庫——用Mycat，這一篇就夠了！

---

歡迎你們關注個人公衆號交流、學習、第一時間獲取最新的文章。
微信號：itmifen