久久国产午夜精品理论,v视界2021

你會從哪些維度進行MySQL性能優(yōu)化？你會怎么回答？

所謂的性能優(yōu)化，一般針對的是MySQL查詢的優(yōu)化。既然是優(yōu)化查詢，我們自然要先知道查詢操作要經過哪些環(huán)節(jié)，然后思考可以在哪些環(huán)節(jié)進行優(yōu)化。

下面從5個角度介紹一下MySQL優(yōu)化的一些策略。

image-20220405204100602

1. 連接配置優(yōu)化

處理連接是MySQL客戶端和MySQL服務端親熱的第一步，第一步都邁不好，也就別談后來的故事了。

既然連接是雙方的事情，我們自然從服務端和客戶端兩個方面來進行優(yōu)化嘍。

1.1 服務端配置

服務端需要做的就是盡可能地多接受客戶端的連接，或許你遇到過error 1040: Too many connections的錯誤？就是服務端的胸懷不夠寬廣導致的，格局太??！

我們可以從兩個方面解決連接數(shù)不夠的問題：

增加可用連接數(shù)，修改環(huán)境變量max_connections，默認情況下服務端的最大連接數(shù)為151個

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.01 sec)

及時釋放不活動的連接，系統(tǒng)默認的客戶端超時時間是28800秒（8小時），我們可以把這個值調小一點

mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.01 sec)

MySQL有非常多的配置參數(shù)，并且大部分參數(shù)都提供了默認值，默認值是MySQL作者經過精心設計的，完全可以滿足大部分情況的需求，不建議在不清楚參數(shù)含義的情況下貿然修改。

1.2 客戶端優(yōu)化

客戶端能做的就是盡量減少和服務端建立連接的次數(shù)，已經建立的連接能湊合用就湊合用，別每次執(zhí)行個SQL語句都創(chuàng)建個新連接，服務端和客戶端的資源都吃不消啊。

解決的方案就是使用連接池來復用連接。

常見的數(shù)據(jù)庫連接池有DBCP、C3P0、阿里的Druid、Hikari，前兩者用得很少了，后兩者目前如日中天。

但是需要注意的是連接池并不是越大越好，比如Druid的默認最大連接池大小是8，Hikari默認最大連接池大小是10，盲目地加大連接池的大小，系統(tǒng)執(zhí)行效率反而有可能降低。為什么？

對于每一個連接，服務端會創(chuàng)建一個單獨的線程去處理，連接數(shù)越多，服務端創(chuàng)建的線程自然也就越多。而線程數(shù)超過CPU個數(shù)的情況下，CPU勢必要通過分配時間片的方式進行線程的上下文切換，頻繁的上下文切換會造成很大的性能開銷。

Hikari官方給出了一個PostgreSQL數(shù)據(jù)庫連接池大小的建議值公式，CPU核心數(shù)*2+1。假設服務器的CPU核心數(shù)是4，把連接池設置成9就可以了。這種公式在一定程度上對其他數(shù)據(jù)庫也是適用的，大家面試的時候可以吹一吹。

2. 架構優(yōu)化

2.1 使用緩存

系統(tǒng)中難免會出現(xiàn)一些比較慢的查詢，這些查詢要么是數(shù)據(jù)量大，要么是查詢復雜（關聯(lián)的表多或者是計算復雜），使得查詢會長時間占用連接。

如果這種數(shù)據(jù)的實效性不是特別強（不是每時每刻都會變化，例如每日報表），我們可以把此類數(shù)據(jù)放入緩存系統(tǒng)中，在數(shù)據(jù)的緩存有效期內，直接從緩存系統(tǒng)中獲取數(shù)據(jù)，這樣就可以減輕數(shù)據(jù)庫的壓力并提升查詢效率。

緩存的使用

2.2 讀寫分離（集群、主從復制）

項目的初期，數(shù)據(jù)庫通常都是運行在一臺服務器上的，用戶的所有讀寫請求會直接作用到這臺數(shù)據(jù)庫服務器，單臺服務器承擔的并發(fā)量畢竟是有限的。

針對這個問題，我們可以同時使用多臺數(shù)據(jù)庫服務器，將其中一臺設置為為小組長，稱之為master節(jié)點，其余節(jié)點作為組員，叫做slave。用戶寫數(shù)據(jù)只往master節(jié)點寫，而讀的請求分攤到各個slave節(jié)點上。這個方案叫做 讀寫分離 。給組長加上組員組成的小團體起個名字，叫集群。

這就是集群

注：很多開發(fā)者不滿master-slave這種具有侵犯性的詞匯（因為他們認為會聯(lián)想到種族歧視、黑人奴隸等），所以發(fā)起了一項更名運動。

受此影響MySQL也會逐漸停用master、slave等術語，轉而用source和replica替代，大家碰到的時候明白即可。

使用集群必然面臨一個問題，就是多個節(jié)點之間怎么保持數(shù)據(jù)的一致性。畢竟寫請求只往master節(jié)點上發(fā)送了，只有master節(jié)點的數(shù)據(jù)是最新數(shù)據(jù)，怎么把對master節(jié)點的寫操作也同步到各個slave節(jié)點上呢？

主從復制技術來了！我在一條SQL更新語句是如何執(zhí)行的？中粗淺地介紹了一下binlog日志，我直接搬過來了。

binlog是實現(xiàn)MySQL主從復制功能的核心組件。master節(jié)點會將所有的寫操作記錄到binlog中，slave節(jié)點會有專門的I/O線程讀取master節(jié)點的binlog，將寫操作同步到當前所在的slave節(jié)點。

主從復制

這種集群的架構對減輕主數(shù)據(jù)庫服務器的壓力有非常好的效果，但是隨著業(yè)務數(shù)據(jù)越來越多，如果某張表的數(shù)據(jù)量急劇增加，單表的查詢性能就會大幅下降，而這個問題是讀寫分離也無法解決的，畢竟所有節(jié)點存放的是一模一樣的數(shù)據(jù)啊，單表查詢性能差，說的自然也是所有節(jié)點性能都差。

這時我們可以把單個節(jié)點的數(shù)據(jù)分散到多個節(jié)點上進行存儲，這就是 分庫分表 。