前言

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

合理預估數據量

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

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

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

合理預估并發訪問量

數據庫有天然的瓶頸，就是并發量。我們一般會通過緩存來減少數據庫的并發連接，以及對數據庫的操作，數據庫的并發，不是只有大型平臺才會遇到，很多中小平臺其實也會面臨這樣的問題，例如：

循環進行數據庫的操作

這個問題，上一篇文章我也提到過，不要在循環里進行數據庫的操作，這個會直接導致數據庫連接數暴增，影響非常嚴重。雖然是個比較低級的問題，但是出現的概率其實是非常高的，在我身邊看到很多很多這種案例了，這種問題，就是需要程序員自己本身避免這些問題，當然，也可以通過一些手段去監控，找到這些問題，只是會比較麻煩一點。

業務本身的高頻次數據請求

其實有些業務，即使是中小型的平臺，也會有高并發請求數據庫的情況，常見的例子如：日志。例如，我們需要抓取到所有人的操作日志，或者所有模塊的加載時間，并且持久化保存。如果，當初選型通過Mysql去記錄這些數據，那么就很容易遇到高并發的問題。這種就是屬于選型的錯誤了。

數據庫對高并發的處理一直是短板，所以應該盡量避免高并發的數據庫操作，查詢通過緩存處理，增刪改這可以通過MQ或者Kafka這樣的工具異步進行處理，如果對數據庫的結構化要求不高，則可以用hbase或者hive進行數據庫的保存。

數據庫線程池的合理使用

現在數據庫的操作都是使用線程池的，線程池主要是用來控制數據庫的連接數，其實連接池是不屬于數據庫范疇，但是，一般我們使用和數據庫結合非常緊密，所以在這里一并說明。
一般線程池都會有這樣的幾個參數：

參數說明

最小連接數	不管是否有數據庫的操作，這幾個連接都會一直存在，
最大連接數	允許的最大的連接數，如果超過了這個數據，則無法申請連接，只能等待，或者異常
回收時間	多長時間會對所有的連接進行一次斷開，然后重新連接。
釋放時間	多長時間沒有進行操作的連接，會釋放

基本所有的連接池都會有這幾個參數，可能不同的連接池參數名不同，但是作用是一樣的。 這里我們重點說一下最大連接數，這個是很容易忽略的一個設置。
很多人設置最大連接數的時候，喜歡設置的很大，例如設置為5000，但是一般mysql的數據庫一個實例連接默認才1000，連接數超過這個了數據庫也無法處理，設置的再大其實是沒用的。

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

而且，這還是在一個實例，一個數據庫的情況下，至于多個數據庫：
我建議

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

如果單個數據庫占用了太多的數據庫連接，會影響到其他數據庫，導致其他數據庫也無法使用。
當然，這個值大家可以根據業務去進行合理的估算，高頻的業務分配多一點，低頻的業務分配少一點。不要盲目的一味設置連接池的最大值。

總結

如今，雖然各種各樣的存儲方式出現，但是關系數據庫一直是我們系統的最重要的組成部分，盡量不要過早暴露數據庫應對并發的短板，設計數據庫和操作數據庫在我們的開發中應該是一件很神圣的事情，認證對待關系的數據庫的每一個操作才是明智之舉。

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

---

歡迎大家關注我的公眾號交流、學習、第一時間獲取最新的文章。
微信號：itmifen

轉載于:https://juejin.im/post/5b8369236fb9a019ec69ff75

總結

以上是生活随笔為你收集整理的数据库的使用你可能忽略了这些 (续)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。