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

如圖所示,主從服務器之間沒有任何主從復制組件,即當主服務器出現(xiàn)了故障,很難進行主服務器的切換,這需要DBA在從服務器中選擇數(shù)據(jù)最新的從服務器將其提升為主服務器并同步其他從服務器,這個過程的時間成本也是非常沉重的。
且過多的從服務器,當業(yè)務量大時對主服務器的網(wǎng)卡也是一定的挑戰(zhàn)。
我們可以通過對集群的監(jiān)控信息來了解是什么影響了數(shù)據(jù)庫性能。
答應其實是肯定的,一般情況下主要是QPS與TPS、并發(fā)量(同一時間處理的請求的數(shù)量,避免和同時連接數(shù)混淆)、磁盤IO、讀操作過于高
這里有個建議:最好不要在主庫上數(shù)據(jù)備份,起碼在大型活動前要取消這類計劃、
影響數(shù)據(jù)庫的因素
- sql查詢速度
- 服務器硬件
- 網(wǎng)卡流量
- 磁盤IO
超高的QPS和TPS
風險:效率底下的SQL(QPS:每秒鐘處理的查詢量)
大量的并發(fā)和超高的CPU使用率
風險:大量的并發(fā)(數(shù)據(jù)庫連接數(shù)被占滿(max_connections默認100))
風險:超高的CPU使用率(因CPU資源耗盡而出現(xiàn)宕機)
磁盤IO
風險:磁盤IO性能突然下降(使用更快的磁盤設備)
風險:其他大量消耗磁盤性能的計劃任務(調(diào)整計劃任務)
網(wǎng)卡流量
風險:網(wǎng)卡IO被占滿(1000Mb/8=100MB)
如何避免無法連接數(shù)據(jù)庫的情況:
1、減少從服務器的數(shù)量
2、進行分級緩存
3、避免使用“select * ”進行查詢
4、分離業(yè)務網(wǎng)絡和服務器網(wǎng)絡
相關文章
mysqld-nt: Out of memory (Needed 1677720 bytes)解決方法
這篇文章主要介紹了mysqld-nt: Out of memory (Needed 1677720 bytes)解決方法,需要的朋友可以參考下2014-12-12
MySQL使用IF語句及用case語句對條件并結果進行判斷?
這篇文章主要介紹了MySQL使用IF語句及用case語句對條件并結果進行判斷,文章通過圍繞主題展開詳細的內(nèi)容介紹,具有一定的參考價值,需要的小伙伴可以參考一下2022-09-09
Windows?Server?2019?MySQL數(shù)據(jù)庫的安裝與配置理論+遠程連接篇
mysql是一款關系型數(shù)據(jù)庫管理系統(tǒng),由MySQL?AB公司開發(fā),目前屬于Oracle旗下產(chǎn)品,MySQL是最流行的關系型數(shù)據(jù)庫管理系統(tǒng)之一。MySQL也是一款開源的SQL數(shù)據(jù)庫管理系統(tǒng),是眾多小型網(wǎng)站作為網(wǎng)站數(shù)據(jù)庫的首選數(shù)據(jù)庫2023-05-05

