關(guān)于數(shù)據(jù)庫性能的故事

面試時多多少少會講到數(shù)據(jù)庫上的事情，“你對數(shù)據(jù)庫的掌握如何？”，什么時候最考驗數(shù)據(jù)庫的性能，答應(yīng)主要方面上講就是大數(shù)據(jù)量的讀寫時，而電商類的大促活動就是考驗各自的數(shù)據(jù)庫性能的時候啦。

對于web服務(wù)器而言，數(shù)據(jù)量大時，我們可以簡單的通過橫向擴(kuò)展來減少單個服務(wù)器的負(fù)擔(dān)，但是對于數(shù)據(jù)庫服務(wù)器來說就沒有那么簡單了，他們不可能做到輕易的橫向擴(kuò)展，這樣也違背了數(shù)據(jù)庫的完整性與一致性的原則，那么我們的數(shù)據(jù)庫架構(gòu)該如何搭建呢？

對于大促類活動而言，不管是產(chǎn)品多好、策劃多成功，如果沒有穩(wěn)定的數(shù)據(jù)庫及服務(wù)器環(huán)境，則這所謂的一切都將是一場空呀。

數(shù)據(jù)庫架構(gòu)案例

如圖所示，主從服務(wù)器之間沒有任何主從復(fù)制組件，即當(dāng)主服務(wù)器出現(xiàn)了故障，很難進(jìn)行主服務(wù)器的切換，這需要DBA在從服務(wù)器中選擇數(shù)據(jù)最新的從服務(wù)器將其提升為主服務(wù)器并同步其他從服務(wù)器，這個過程的時間成本也是非常沉重的。

且過多的從服務(wù)器，當(dāng)業(yè)務(wù)量大時對主服務(wù)器的網(wǎng)卡也是一定的挑戰(zhàn)。

我們可以通過對集群的監(jiān)控信息來了解是什么影響了數(shù)據(jù)庫性能。

答應(yīng)其實(shí)是肯定的，一般情況下主要是QPS與TPS、并發(fā)量（同一時間處理的請求的數(shù)量，避免和同時連接數(shù)混淆）、磁盤IO、讀操作過于高

這里有個建議：最好不要在主庫上數(shù)據(jù)備份，起碼在大型活動前要取消這類計劃、

影響數(shù)據(jù)庫的因素

• sql查詢速度
• 服務(wù)器硬件
• 網(wǎng)卡流量
• 磁盤IO

超高的QPS和TPS

風(fēng)險：效率底下的SQL(QPS：每秒鐘處理的查詢量)

大量的并發(fā)和超高的CPU使用率

風(fēng)險：大量的并發(fā)（數(shù)據(jù)庫連接數(shù)被占滿（max_connections默認(rèn)100））

風(fēng)險：超高的CPU使用率（因CPU資源耗盡而出現(xiàn)宕機(jī)）

磁盤IO

風(fēng)險：磁盤IO性能突然下降（使用更快的磁盤設(shè)備）

風(fēng)險：其他大量消耗磁盤性能的計劃任務(wù)（調(diào)整計劃任務(wù)）

網(wǎng)卡流量

風(fēng)險：網(wǎng)卡IO被占滿（1000Mb/8=100MB）

如何避免無法連接數(shù)據(jù)庫的情況：

1、減少從服務(wù)器的數(shù)量
2、進(jìn)行分級緩存
3、避免使用“select * ”進(jìn)行查詢
4、分離業(yè)務(wù)網(wǎng)絡(luò)和服務(wù)器網(wǎng)絡(luò)