Mysql優化（通用版）

• 一、優化方向
• 二、優化方法
• • 1、監控分析
  • 2、改變 SQL 執行計劃
• 三、軟優化
• • 1、查詢語句優化
  • 2、優化子查詢
  • 3、使用索引
  • 4、分解表
  • 5、增加中間表
  • 6、增加冗余字段
  • 7、選擇合適的引擎
  • 8、分析表、檢查表、優化表
  • 9、視圖的使用
• 四、硬優化
• • 1、CPU、內存、磁盤
  • 2、參數（提高資源利用率——》提高MySQL服務器性能）
  • 3、分庫分表
• 五、架構優化
• • 1、主從復制
  • • ①、異步復制
    • ②、全同步復制
    • ③、半同步復制
  • 2、讀寫分離
  • 3、MHA高可用
  • 4、proxySQL代理

一、優化方向

二、優化方法

1、監控分析

• 硬件資源監控
  • 關注的主要數據庫服務器在IO和CPU方面的指標。
• mysql性能分析器
  • 可以利用 mysql profiling（mysql性能分析器）來優化sql語句，即查看SQL執行消耗系統資源的信息（需要開啟才能應用該功能）。
• 慢查詢分析
  • 通過慢日志查詢可以知道哪些SQL語句執行效率低下，那些sql語句使用的頻率高等。

對MySQL查詢語句的監控、分析、優化是MySQL優化非常重要的一步。開啟慢查詢日志后，由于日志記錄操作，在一定程度上會占用CPU資源影響mysql的性能，但是可以階段性開啟來定位性能瓶頸。

2、改變 SQL 執行計劃

使用explain命令查看query語句的性能

• id：id主要是用來標識sql執行順序，如果沒有子查詢，一般來說id只有1個，執行順序也是從上到下。
• select_type：每個select子句的類型，主要分成下面幾種：
  • SIMPLE：查詢中不包含任何子查詢或者union
  • PRIMARY：查詢中包含了任何復雜的子部分，最外層的就會變成PRIMARY
  • SUBQUERY：在SELECT或者WHERE列表中包含了子查詢
  • DERIVED：在FROM中包含了子查詢
  • UNION：如果第二個SELECT出現在UNION之后，則被標記為UNION，如果UNION包含在FROM子句的子查詢中，外層SELECT會被標記為：DERIVED
  • UNION RESULT從UNION表獲取結果的select
• type：是指MySQL在表中找到所需行的方式，也就是訪問行的“類型”，從 all 開始，效率逐漸上升：
  • all：全表掃描，效率最低
  • index：index會根據索引樹遍歷
  • range：索引范圍掃描，返回匹配值域的行。
  • ref：非唯一性索引掃描，返回匹配某個單獨值的所有行。一般是指多列的唯一索引中的某一列。
  • eq_ref：唯一性索引掃描，表中只有一條記錄與之匹配。
  • const、system：主要針對查詢中有常量的情況，如果結果只有一行會變成system
  • NULL：顯而易見，既不走表，也不走索引
• possible_keys
  • possible_keys列預估了mysql能夠為當前查詢選擇的索引，這個字段是完全獨立于執行計劃中輸出的表的順序，意味著在實際查詢中可能用不到這些索引。
  • 如果該字段為空則意味著沒有可使用的索引，這個時候你可以考慮為where后面的字段建立索引。
• key
  • 這個字段表示了mysql真實使用的索引（如果為NULL，則沒有使用索引）。如果mysql優化過程中沒有加索引，可以強制加hint使用索引。
• key_len
  • 索引長度字段顧名思義，表示了mysql查詢中使用的索引的長度（最大可能長度），并非實際使用長度，理論上長度越短越好。key_len是根據表定義計算而得的，不是通過表內檢索出的。
• ref
  • 這個字段一般是指一些常量用于選擇過濾（顯示索引的那一列被使用了，如果可能，是一個常量const）。
• rows
  • 預估結果集的條數，可能不一定完全準確（根據表統計信息及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數）。
• Extra
  • 不適合在其他字段中顯示，但是十分重要的額外信息：
    • Using filesort：mysql對數據使用一個外部的索引排序，而不是按照表內的索引進行排序讀取。也就是說mysql無法利用索引完成的排序操作成為“文件排序”。
    • Using temporary：使用臨時表保存中間結果，也就是說mysql在對查詢結果排序時使用了臨時表，常見于order by 和 group by。
    • Using index：表示相應的 select 操作中使用了覆蓋索引（Covering Index），避免了訪問表的數據行，這樣提高了效率（不使用select *）；如果同時出現Using where，表明索引被用來執行索引鍵值的查找；如果沒用同時出現Using where，表明索引用來讀取數據而非執行查找動作。
    • Using join buffer：使用了鏈接緩存。
    • eq_ref:唯一性索引掃描，表中只有一條記錄與之匹配。
    • Impossible WHERE：where子句的值總是false，不能用來獲取任何元祖。
    • select tables optimized away：在沒有group by子句的情況下，基于索引優化MIN/MAX操作或者對于MyISAM存儲引擎優化COUNT（*）操作，不必等到執行階段在進行計算，查詢執行計劃生成的階段即可完成優化。
    • distinct：優化distinct操作，在找到第一個匹配的元祖后即停止找同樣值得動作。

三、軟優化

1、查詢語句優化

• EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執行信息，查看其中的不足，予以改善

2、優化子查詢

• 在MySQL中，盡量使用JOIN來代替子查詢，因為子查詢需要嵌套查詢，嵌套查詢時會建立一張臨時表，臨時表的建立和刪除都會有較大的系統開銷，而連接查詢不會創建臨時表，因此效率比嵌套子查詢高。

3、使用索引

• 根據情況，創建合適的索引
  • 主鍵、唯一鍵會自動創建索引
  • 外鍵也必須有索引，因為外鍵是子表的主鍵關連建，能更快速的定位子表內容
  • 使用唯一性較好的、更新不是很頻繁的、經常與其他表進行連接的字段作為索引
  • 經常出現在 where 語句中的字段，需要做索引，會更好的方便我們處理日常事務，節約時間成本
  • 選擇性較高的字段需要做索引
  • 超長字段，建議做全文索引，或者不建立索引

4、分解表

• 對于字段較多的表，如果某些字段使用頻率較低，此時應當，將其分離出來從而形成新的表。
• 大表拆分成多個小表，之間進行外鍵關聯，提高查詢效率。

5、增加中間表

• 對于將大量連接查詢的表可以創建中間表，從而減少在查詢時造成的連接耗時。

6、增加冗余字段

• 類似于創建中間表，增加冗余也是為了減少連接查詢。

7、選擇合適的引擎

• 根據不同的使用場景，分配不同的數據庫引擎，提高效率。

8、分析表、檢查表、優化表

• 分析表主要是分析表中關鍵字的分布，檢查表主要是檢查表中是否存在錯誤，優化表主要是消除刪除或更新造成的表空間浪費。

9、視圖的使用

• 把表的一個子集進行排序并創建視圖，有時能加速查詢（特別是要被多次執行的查詢）。它有助于避免多重排序操作，而且在其他方面還能簡化優化器的工作。視圖中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁盤I/O，所以查詢工作量可以得到大幅減少。

四、硬優化

1、CPU、內存、磁盤

• 配置多核心和頻率高的cpu,多核心可以執行多個線程.
• 配置大內存,提高內存,即可提高緩存區容量,因此能減少磁盤I/O時間,從而提高響應速度.
• 配置高速磁盤或合理分布磁盤:高速磁盤提高I/O,分布磁盤能提高并行操作的能力.

2、參數（提高資源利用率——》提高MySQL服務器性能）

• key_buffer_size：索引緩沖區大小
• table_cache：能同時打開表的個數
• query_cache_size和query_cache_type：前者是查詢緩沖區大小，后者是前面參數的開關，0表示不使用緩沖區，1表示使用緩沖區，但可以在查詢中使用SQL_NO_CACHE表示不要使用緩沖區，2表示在查詢中明確指出使用緩沖區才用緩沖區，即SQL_CACHE
• sort_buffer_size：排序緩沖區

3、分庫分表

• 當遇到高并發環境時，數據庫壓力可能過大，系統性能可能會降低，因為數據庫負載過高對性能會有影響，可能導致數據庫宕機
• 為防止宕機情況發生，可以把一個庫拆分為多個庫，部署在多個數據庫服務上，這時作為主庫承載寫入請求。然后每個主庫都掛載至少一個從庫，由從庫來承載讀請求。

五、架構優化

1、主從復制

主從復制簡單地說，就是主服務器通過dump線程把數據寫入二進制日志，然后從服務器通過IO線程的請求，把二進制日志同步到自身的中繼日志中，接著通過SQL線程，把SQL語句在自己的庫執行一遍，以達到數據同步的目的。

①、異步復制

默認復制為異步復制，主庫在執行完客戶端提交的事務后立即返回客戶端，并不需要等待從服務器是否同步完成，這樣就有一個時間差，這時候如果出現了主服務器出現災難性問題，可能會導致從服務器數據沒有完全同步完成，造成數據的丟失

②、全同步復制

當主庫在執行完客戶端提交的事務后，會等待所有從服務器也執行完該事務后，才能返回客戶端，所以全同步復制的性能必然會受到嚴重的影響。

③、半同步復制

介于異步和全同步之間，主庫在執行完客戶端提交的事務后，會等待至少一個從庫接收并寫入中繼日志后才會返回客戶端。
相對于異步復制，半同步復制提高了數據的安全性，但也相對的造成了一定程度的延遲

2、讀寫分離

讀寫分離簡單的說是把對數據庫讀和寫的操作分開對應不同的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕IO壓力。主數據庫提供寫操作，從數據庫提供讀操作，其實在很多系統中，主要是讀的操作。當主數據庫進行寫操作時，數據要同步到從的數據庫，這樣才能有效保證數據庫完整性

3、MHA高可用

MHA（MasterHigh Availability）是一套優秀的MySQL高可用環境下故障切換和主從復制的軟件。當主服務器出現故障時，MHA能做到0-30秒內自動完成故障切換操作，讓VIP漂移到備選的服務器上，以保證服務的不中斷運行，給我們爭取了搶修主服務器的時間。

4、proxySQL代理

• proxySQL代理功能：
  • 最基本的讀/寫分離，且方式有多種
  • 可定制基于用戶、基于schema、基于語句的規則對SQL語句進行路由。換句話說，規則很靈活。基于schema和與語句級的規則，可以實現簡單的sharding(分庫分表)
  • 可緩存查詢結果。雖然ProxySQL的緩存策略比較簡陋，但實現了基本的緩存功能，絕大多數時候也夠用了。
  • 監控后端節點。ProxySQL可以監控后端節點的多個指標，包括：ProxySQL和后端的心跳信息，后端節點的read-only/read-write，slave和master的數據同步延遲性(replication lag)

總結

以上是生活随笔為你收集整理的瞬间带你了解如何优化 Mysql 数据库，老板再也不担心客户投诉了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。