前言

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

合理預(yù)估數(shù)據(jù)量

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

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

很多系統(tǒng)因為在設(shè)計表的時候，沒有很好的預(yù)估的后期系統(tǒng)的發(fā)展，導(dǎo)致上線不久就出現(xiàn)無法支撐的情況，代碼上太多的聯(lián)表查詢，不在乎基礎(chǔ)的SQL性能，導(dǎo)致數(shù)據(jù)庫的瓶頸很快就顯現(xiàn)出來，不得不重構(gòu)系統(tǒng)。設(shè)計數(shù)據(jù)庫的時候，一定是基于業(yè)務(wù)進行設(shè)計的，對業(yè)務(wù)的發(fā)展有一定的預(yù)估，看得長遠一點。

合理預(yù)估并發(fā)訪問量

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

循環(huán)進行數(shù)據(jù)庫的操作

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

業(yè)務(wù)本身的高頻次數(shù)據(jù)請求

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

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

數(shù)據(jù)庫線程池的合理使用

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

參數(shù)說明

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

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

服務(wù)器數(shù)量 * 最大連接數(shù) < 數(shù)據(jù)庫最大連接數(shù)

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

服務(wù)器數(shù)量 * 最大連接數(shù) * 數(shù)據(jù)庫數(shù)量 < 數(shù)據(jù)庫最大連接數(shù)

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

總結(jié)

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

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

---

歡迎大家關(guān)注我的公眾號交流、學(xué)習(xí)、第一時間獲取最新的文章。
微信號：itmifen

轉(zhuǎn)載于:https://juejin.im/post/5b8369236fb9a019ec69ff75

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。