關(guān)于數(shù)據(jù)庫性能的故事
面試時(shí)多多少少會(huì)講到數(shù)據(jù)庫上的事情,“你對(duì)數(shù)據(jù)庫的掌握如何?”,什么時(shí)候最考驗(yàn)數(shù)據(jù)庫的性能,答應(yīng)主要方面上講就是大數(shù)據(jù)量的讀寫時(shí),而電商類的大促活動(dòng)就是考驗(yàn)各自的數(shù)據(jù)庫性能的時(shí)候啦。
對(duì)于web服務(wù)器而言,數(shù)據(jù)量大時(shí),我們可以簡(jiǎn)單的通過橫向擴(kuò)展來減少單個(gè)服務(wù)器的負(fù)擔(dān),但是對(duì)于數(shù)據(jù)庫服務(wù)器來說就沒有那么簡(jiǎn)單了,他們不可能做到輕易的橫向擴(kuò)展,這樣也違背了數(shù)據(jù)庫的完整性與一致性的原則,那么我們的數(shù)據(jù)庫架構(gòu)該如何搭建呢?
對(duì)于大促類活動(dòng)而言,不管是產(chǎn)品多好、策劃多成功,如果沒有穩(wěn)定的數(shù)據(jù)庫及服務(wù)器環(huán)境,則這所謂的一切都將是一場(chǎng)空呀。
數(shù)據(jù)庫架構(gòu)案例

如圖所示,主從服務(wù)器之間沒有任何主從復(fù)制組件,即當(dāng)主服務(wù)器出現(xiàn)了故障,很難進(jìn)行主服務(wù)器的切換,這需要DBA在從服務(wù)器中選擇數(shù)據(jù)最新的從服務(wù)器將其提升為主服務(wù)器并同步其他從服務(wù)器,這個(gè)過程的時(shí)間成本也是非常沉重的。
且過多的從服務(wù)器,當(dāng)業(yè)務(wù)量大時(shí)對(duì)主服務(wù)器的網(wǎng)卡也是一定的挑戰(zhàn)。
我們可以通過對(duì)集群的監(jiān)控信息來了解是什么影響了數(shù)據(jù)庫性能。
答應(yīng)其實(shí)是肯定的,一般情況下主要是QPS與TPS、并發(fā)量(同一時(shí)間處理的請(qǐng)求的數(shù)量,避免和同時(shí)連接數(shù)混淆)、磁盤IO、讀操作過于高
這里有個(gè)建議:最好不要在主庫上數(shù)據(jù)備份,起碼在大型活動(dòng)前要取消這類計(jì)劃、
影響數(shù)據(jù)庫的因素
- sql查詢速度
- 服務(wù)器硬件
- 網(wǎng)卡流量
- 磁盤IO
超高的QPS和TPS
風(fēng)險(xiǎn):效率底下的SQL(QPS:每秒鐘處理的查詢量)
大量的并發(fā)和超高的CPU使用率
風(fēng)險(xiǎn):大量的并發(fā)(數(shù)據(jù)庫連接數(shù)被占滿(max_connections默認(rèn)100))
風(fēng)險(xiǎn):超高的CPU使用率(因CPU資源耗盡而出現(xiàn)宕機(jī))
磁盤IO
風(fēng)險(xiǎn):磁盤IO性能突然下降(使用更快的磁盤設(shè)備)
風(fēng)險(xiǎn):其他大量消耗磁盤性能的計(jì)劃任務(wù)(調(diào)整計(jì)劃任務(wù))
網(wǎng)卡流量
風(fēng)險(xiǎn):網(wǎng)卡IO被占滿(1000Mb/8=100MB)
如何避免無法連接數(shù)據(jù)庫的情況:
1、減少從服務(wù)器的數(shù)量
2、進(jìn)行分級(jí)緩存
3、避免使用“select * ”進(jìn)行查詢
4、分離業(yè)務(wù)網(wǎng)絡(luò)和服務(wù)器網(wǎng)絡(luò)
您可能感興趣的文章:- MySQL中聚合函數(shù)count的使用和性能優(yōu)化技巧
- mysql查詢時(shí)offset過大影響性能的原因和優(yōu)化詳解
- MySQL優(yōu)化insert性能的方法示例
- MySQL性能全面優(yōu)化方法參考,從CPU,文件系統(tǒng)選擇到mysql.cnf參數(shù)優(yōu)化
- 淺談MySQL和MariaDB區(qū)別(mariadb和mysql的性能比較)
- mysql千萬級(jí)數(shù)據(jù)分頁查詢性能優(yōu)化
- mysql分頁性能探索
- MySQL批量SQL插入性能優(yōu)化詳解
- MySQL幾點(diǎn)重要的性能指標(biāo)計(jì)算和優(yōu)化方法總結(jié)