作為一名DBA你是否遇到這種情況?當(dāng)你埋頭認(rèn)真工作之時(shí)，發(fā)現(xiàn)自己操作的數(shù)據(jù)庫變得越來越慢，甚至是卡頓。如何處理?是什么原因?qū)е履愕腗ySQL運(yùn)行速度變慢呢?

[[274174]]

下面小編將帶大家從多方面進(jìn)行分析是什么導(dǎo)致MySQL數(shù)據(jù)庫變慢~

一、 外部的硬件因素

能夠直接影響MySQL服務(wù)器性能的系統(tǒng)指標(biāo)有：CPU、內(nèi)存、磁盤等的使用情況。

使用 vmstart 查看服務(wù)器資源使用情況：

根據(jù)上面的反饋結(jié)果，可以看得出磁盤的數(shù)據(jù)寫入比較大、CPU負(fù)載較高，這時(shí)需要對(duì)正在運(yùn)行的程序進(jìn)行優(yōu)化，減小資源負(fù)載。

二、 使用不恰當(dāng)?shù)腟QL語句

例如：

1)在第一條SQL語句中，where 查詢語句中出現(xiàn)了 null，這時(shí)數(shù)據(jù)庫的引擎不會(huì)使用索引，而是對(duì)全表進(jìn)行一次掃描，這樣的查詢將導(dǎo)致數(shù)據(jù)庫變慢。

解決方法：使用0來代替null，即第二條SQL語句，可以加快數(shù)據(jù)庫查詢速度。

2)在查詢的數(shù)據(jù)表當(dāng)中如果使用 update、delete、insert 過于頻繁，我們可以嘗試使用optimize table 來存放，索引，存儲(chǔ)文件。

3)Select for update 如果條件的字段沒有使用索引的話，就會(huì)導(dǎo)致對(duì)全表進(jìn)行查詢，而不是對(duì)特定的行進(jìn)行查詢，需要注意。

下面第一條SQL語句的效率要比第二條SQL語句高的多。因?yàn)榈谝粭lSQL語句使用的索引查詢;第二條SQL語句是將表中所有的數(shù)據(jù)都檢索一遍，相當(dāng)于全表查詢，比較慢和消耗資源。

三、 MySQL參數(shù)設(shè)置有問題

1. max_connect_errors

我們知道「max_connect_errors 」正常情況下的默認(rèn)值是10，它是用來表示受信賬號(hào)錯(cuò)誤的連接次數(shù)， 當(dāng)這個(gè)次數(shù)達(dá)到了10之后，MySQL服務(wù)器就會(huì)被自動(dòng)阻塞住了。 例如下圖這樣的錯(cuò)誤：

解決方法：

當(dāng)出現(xiàn)這樣的錯(cuò)誤時(shí)，我們需要 flush hosts 來解除錯(cuò)誤。其中，max_connect_errors 表示連接中斷重復(fù)請(qǐng)求連接的次數(shù)。

對(duì)于內(nèi)網(wǎng)而言，建議將 max_connect_errors 的數(shù)量設(shè)置大于10000，這樣就不會(huì)輕易阻塞，并且你還得定期進(jìn)行 flush hosts.

2.  connect_timeout

「connect_timeout」表示的是MySQL等待應(yīng)答連接報(bào)文的最大秒數(shù)，當(dāng)超過這個(gè)時(shí)間后，表示 MySQL 連接失敗了。 這個(gè)值默認(rèn)值是5S，所以當(dāng)系統(tǒng)在處于高并發(fā)狀態(tài)下，很容易超時(shí)，因此建議將 connect_timeout 設(shè)置為10-15秒為宜。

3. master-connect-retry

「master-connect-retry」表示的是在重新建立主從連接時(shí)，出現(xiàn)連接失敗后，間隔多久可以重試上述過程。 建議將此值設(shè)置大一些。