mysql效能優化總結 一

2022-06-09 18:42:07 字數 3993 閱讀 9194

一.什麼決定雙11大促的成敗?

場景:原資料庫架構為1m15s,m伺服器效能很好,64核512g記憶體,io採用fushion io,比一般磁碟的讀寫能力高很多.

缺點:1.只有乙個主庫,沒有主從切換中介軟體,每次如果主庫掛了,需要運維人員手動進行切換,然後同步給其他從庫,耗時高(超過半小時不可用)

2.雙十一凌晨2點半資料庫磁碟io達到峰值,造成恐慌,擔心效能為急劇下降.經檢查,發現是資料庫遠端備份定時任務在跑,總結:最好不要在主庫上進行資料庫備份,大型活動前取消這類計畫.

對資料庫效能影響比較大的因素:

(1)sql效能

(2)網絡卡流量

(3)伺服器硬體

(4)磁碟io

(5)大表

(6)大事務

資料庫面臨的風險:

(1)超高的qps和tps

根據經驗,資料庫效能80%都是由慢查詢導致的.大多數據資料庫問題都可以通過sql效能優化來解決.

當前的mysql不支援單sql語句多cpu併發計算,一條sql只能由乙個cpu去執行.10ms的sql和100ms的sql效能直接相差10倍.

(2)大量的併發和超高的cpu使用率

大量併發:資料庫連線被佔滿.當併發數大於最大連線數時,出現500錯誤,對使用者體驗造成影響.

ps:併發數和連線數的區別:併發是指同時請求mysql的數量,連線數是指mysql的連線數,通常連線數遠大於併發數,因為大部分的連線都是出於sleep狀態.類似於http長連線.

資料庫最大連線數:max_connections,預設值為100.所以需要把這個引數改的大一些.

超高的cpu使用率:可能導致cpu資源耗盡而宕機

(3)磁碟

1.io效能突然下降

常發生在熱資料量遠遠大於伺服器可用記憶體的情況下(使用更快的磁碟裝置來解決.比如fashion io,ssd,更好的raid卡)

2.其他大量損耗磁碟效能的計畫任務(調整計畫任務,做好磁碟維護)

(4)網絡卡流量(1000mb/8≈100mb)

流量高峰期,千兆網絡卡多次被跑滿,其他請求會出現無法連線資料庫. 

解決辦法:

1.減少從資料庫的數量   

2.進行分級快取,避免大量的請求突然對資料庫形成衝擊

3.避免使用select * 進行查詢,查詢出沒有必要的列會浪費網路流量

4.分離業務網路和伺服器網路,避免主從同步或者備份等作業影響網路效能.

什麼是大表:

1.記錄行數巨大,單表達到千萬行

根據場景靈活應用,比如日誌表,只有insert操作和少量的select操作,幾乎沒有update操作和delete操作,這樣的表就算超過了千萬行,也不會對業務產生什麼影響.實際工作中有遇到過,日誌表的行數已經超過10個億了,一直很穩定.但是在增加列的時候,會非常痛苦(為什 麼?)

2.資料檔案巨大,表資料檔案超過10g

大表對查詢的影響:

1.慢查詢:大表意味著很難在一定的時間內,過濾出所需要的的資料

2.對ddl操作的影響

(1)建立索引需要花費很長的時間

mysql版本<5.5,建立索引會鎖表

mysql版本》=5.5,不會鎖表,但是會引起主從延遲

(2)修改表結構需要長時間鎖表

風險:1.會造成長時間的主從延遲.假設主庫修改需要480s,mysql5.6之前主從同步使用的是單執行緒,主庫執行完之後才會同步到從庫執行相同的操作,所以從庫也至少需要480s來完成同步,也就造成了480s的主從延遲,這對於大多數業務來說都是不可接受的.

5.6之後,支援多執行緒複製,但是也有一定的限制.

2.影響正常的資料庫操作(鎖表,其他操作被阻塞),導致資料庫連線數猛增.超過最大連線數後,前台出現500錯誤

如何解決大表問題:

1.分庫分表

2.進行歷史資料歸檔

難點:(1)歸檔是時間點的選擇

(2)如何進行歸檔操作(大表中刪除大量資料,需要注意方式方法,否則輕則造成主從延遲,重則影響使用者正常操作)

大事務對效能的影響

定義:執行時間較長,操作的資料比較多的事務

風險:鎖定太多的資料,造成大量的阻塞和鎖超時.

回滾時所需時間比較長(有可能比執行事務所花費的時間更長)

執行時間長,容易造成主從延遲

解決方法:

1.避免一次性操作太多的資料

2.移出不必要在事務中的select操作

影響效能的幾個方面:

1.計算機硬體,如cpu,記憶體,磁碟io

2.作業系統,windows xp系統預設的併發數只有10個.伺服器效能調優

3.mysql的儲存引擎

myisam:不支援事務,表級鎖

innodb:事務級儲存引擎,完美支援行級鎖,事務acid特性.

4.資料庫引數配置

有些引數對資料庫效能的影響是決定性的.

前面三個方面的影響加起來 < 資料庫引數配置的影響 

5.資料庫表結構設計和sql語句執行效率

慢查詢是很多資料庫效能低下的罪魁禍首.

很多慢查詢是由於資料庫表結構設計不合理導致的,這類問題一旦專案上線就很難再修改了.

重點是前期的優化設計及後期sql優化.

如何選擇cpu?

1.高的頻率,更多的核心核心數.2者不可兼得時,web應用來說,核心數》頻率.cpu密集型應用來說,由於mysql不支援多核併發計算同一條sql,所以頻率也很重要.

2.mysql版本也有影響,5.0之前的版本對於多核cpu的支援是很弱的,5.6,5.7之後做了很好的支援.

3.注意不要出現64位的cpu使用32位的作業系統,大多由於誤裝,對效能限制很大.

如何選擇記憶體?

1.資料庫自帶快取策略,記憶體的大小直接影響資料庫效能,特別是當熱資料大小遠遠大於可用記憶體時.

myisam   

索引->記憶體  

資料->os

innodb

索引,資料->記憶體

2.記憶體並不是越大越好,當記憶體大小大於所有資料量大小,即所有的資料都已經被快取在記憶體中,再增加記憶體就是沒有意義的了.

3.記憶體的大小不僅對查詢有效,對插入也一樣有效.可以做到延緩插入,先快取在記憶體中,然後批量插入,從而減少io操作次數,提高效能.

4.頻率越高越好,選擇主機板能夠支援的頻率最高的記憶體條,然後單個記憶體條盡量的大,所有記憶體條型號保持完全一致.

磁碟的配置和選擇

1.使用傳統機器硬碟

最常見,使用最多,**低,儲存空間大,讀寫速度慢

如何選擇?

1.儲存容量

2.傳輸速度

3.訪問時間

4.主軸轉速(7500,15000)

5.物理尺寸(越小越快)

2.使用raid增強傳統機器硬碟的效能

定義:raid是磁碟冗餘佇列的簡稱,吧多個容量較小的磁碟組成一組容量更大的磁碟,並提供資料冗餘來保證資料完整性的技術

常見raid組別:

(1)raid 0:資料條帶,串聯,成本低,可以提高磁碟效能和吞吐量,沒有提供冗餘和錯誤修復.損壞率比單塊磁碟更高,其中任何一塊磁碟損壞都會造成數丟失.

(2)raid 1:磁碟映象,最大限度的保障可靠性和可修復性,磁碟利用率低(50%)

(3)raid 5:分布式奇偶校驗磁碟陣列,讀快,寫慢,磁碟利用率高,只需要額外一塊磁碟.同時損壞兩塊以上則不可修復.

(4)raid 10:先做raid 1,在做raid 0,讀寫效能好,恢復較raid 5更簡單,速度也更快. 

3.使用固態儲存ssd和pcie卡

更好的隨機讀寫效能

更好的支援併發

缺點:更容易損壞

ssd:使用sata介面,同樣可以使用raid技術,由於頻寬的限制,無法完全發揮快閃儲存器技術的效能

pcie卡:無法使用sata介面,需要特殊的驅動和配置,**比ssd更貴,效能更好.fusion-io,會占用記憶體資源.

如果只有一塊ssd,應該放在從伺服器上,而不是主伺服器上.

4.使用網路儲存nas和san

san和nas是兩種外部檔案儲存裝置載入到伺服器上的方法

mysql效能優化配置總結

看了一些優化mysql運維的一些書籍,在此記錄總結下 進入mysql客戶端輸入以下sql 1 連線設定 show variables like max connection show status like max used connections max used connections max ...

mysql效能優化總結 四

mysql資料庫結構設計和sql優化 資料庫設計對效能的影響 1.過分的反正規化化設計為表建立太多的列 服務層和儲存引擎層之間通過反衝格式來拷貝資料和解析成列,列過多,帶來額外的cpu消耗 2.過分正規化化造成過多的表關聯,mysq最多支援61張表的關聯查詢,需要控制在10個以內 3.使用不恰當的分...

mysql效能優化總結 三

mysql體系結構 外掛程式式儲存引擎,將資料的查詢和儲存相分離.每一款儲存引擎都有各自的優缺點.可以靈活選用 架構 客戶端 mysql服務層 儲存引擎層 儲存引擎是針對表,不是針對庫,同一庫中的不同的表,可以使用不同的儲存引擎.但是不建議這樣做 儲存引擎的不同會對效能產生直接的影響.mysql常用...