Mysql的索引、性能分析與SQL優化

存儲引擎

1.INnnoDB與MyISAM

對比項	MyISAM	INnnoDB
主外鍵	不支持	支持
事物	不支持	支持
行表鎖	表鎖，即使操作一條記錄	行鎖
緩存	只緩存索引，不緩存真實數據	索引與數據都會緩存，堆內存要求較高， 且內存大小對性能有決定性的影響
表空間	小	大
關注點	性能	事物
默認安裝	Y	Y

索引

1.索引的定義

MySQL官方對索引的定義爲：索引(Index)是幫助MySQL高校獲取數據的數據結構。
可以得到索引的本質：索引是數據結構。

數據本身之外,數據庫還維護着一個滿足特定查找算法的數據結構，這些數據結構以某種方式指向數據，
這樣就可以在這些數據結構的基礎上實現高級查找算法,這種數據結構就是索引。

我們平時所說的索引，如果沒有特別指明，都是指B樹(多路搜索樹，並不一定是二叉樹)結構組織的索引。其中聚集索引，次要索引，覆蓋索引，複合索引，前綴索引，唯一索引默認都是使用B+樹索引，統稱索引。當然,除了B+樹這種類型的索引之外，還有哈希索引(hash index)等。

2.索引的優勢

• 類似大學圖書館建書目索引，提高數據檢索效率，降低數據庫的IO成本
• 通過索引列對數據進行排序，降低數據排序成本，降低了CPU的消耗

3.索引的劣勢

• 實際上索引也是一張表，該表保存了主鍵和索引字段，並指向實體表的記錄,所以索引列也是要佔用空間的
• 雖然索引大大提高了查詢速度，同時卻會降低更新表的速度,如果對錶INSERT,UPDATE和DELETE。因爲更新表時，MySQL不僅要不存數據，還要保存一下索引文件每次更新添加了索引列的字段，都會調整因爲更新所帶來的鍵值變化後的索引信息
• 索引只是提高效率的一個因素，如果你的MySQL有大數據量的表，就需要花時間研究建立優秀的索引，或優化查詢語句

4.索引的分類

1. 單值索引
   • 即一個索引只包含單個列，一個表可以有多個單列索引
   • 建議一張表索引不要超過5個，優先考慮複合索引
2. 唯一索引
   • 索引列的值必須唯一，但允許有空值
3. 複合索引
   • 即一個索引包含多個列
4. 基本語法
   • ALTER mytable ADD [UNIQUE] INDEX [indexName] ON(columnname(length));。
   • DROP INDEX [indexName] ON mytable;
   • SHOW INDEX FROM table_name

5.哪些情況需要創建索引

• 主鍵自動建立唯一索引
• 頻繁作爲查詢的條件的字段應該創建索引
• 查詢中與其他表關聯的字段，外鍵關係建立索引
• 頻繁更新的字段不適合創建索引
• Where條件裏用不到的字段不創建索引
• 單間/組合索引的選擇問題，who？（在高併發下傾向創建組合索引）
• 查詢中排序的字段，排序字段若通過索引去訪問將大大提高排序的速度
• 查詢中統計或者分組字段

6.哪些情況不要創建索引

• 表記錄太少
• 經常增刪改的表
• 數據重複且分佈平均的表字段，因此應該只爲經常查詢和經常排序的數據列建立索引。注意，如果某個數據列包含許多重複的內容，爲它建立索引就沒有太大的實際效果。

性能分析

1.執行計劃信息

1. id：select查詢的序列號，包含一組數字，表示查詢中執行select子句或操作表的順序

   包括三種情況

   • id相同，執行順序由上至下
   • id不同，如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行
   • id相同不同，同時存在

2. select_type：查詢的類型，主要用於區別普通查詢、聯合查詢、子查詢等的複雜查詢，包括六種

   • SIMPLE：簡單的select查詢，查詢中不包含子查詢或者UNION
   • PRIMARY：查詢中若包含任何複雜的子部分，最外層查詢則被標記爲
   • SUBQUERY：在SELECT或者WHERE列表中包含了子查詢
   • DERIVED：在FROM列表中包含的子查詢被標記爲DERIVED（衍生）MySQL會遞歸執行這些子查詢，把結果放在臨時表裏。
   • UNION：若第二個SELECT出現在UNION之後，則被標記爲UNION;若UNION包含在FROM子句的子查詢中，外層SELECT將被標記爲：DERIVED
   • UNION RESULT：從UNION表獲取結果的SELECT

3. table：顯示這一行的數據是關於哪張表的

4. type：顯示查詢使用了何種類型，從最好到最差依次是：system>const>eq_ref>ref>range>index>ALL

   • system：表只有一行記錄（等於系統表），這是const類型的特例，平時不會出現，這個也可以忽略不計
   • const：表示通過索引一次就找到了，const用於比較primary key或者unique索引。因爲只匹配一行數據，所以很快。如將主鍵至於where列表中，MySQL就能將該查詢轉換爲一個常量
   • eq_ref：唯一性索引，對於每個索引鍵，表中只有一條記錄與之匹配，常見於主鍵或唯一索引掃描
   • ref：非唯一索引掃描，返回匹配某個單獨值的所有行。本質上也是一種索引訪問，它返回所有匹配某個單獨值的行，然而，它可能會找到多個符合條件的行，所以他應該屬於查找和掃描的混合體
   • range：只檢索給定範圍的行，使用一個索引來選擇行。key列顯示使用了哪個索引一般就是在你的where語句中出現了between、<、>、in等的查詢這種範圍掃描索引掃描比全表掃描要好，因爲他只需要開始索引的某一點，而結束語另一點，不用掃描全部索引
   • index：Full Index Scan,index與ALL區別爲index類型只遍歷索引樹。這通常比ALL快，因爲索引文件通常比數據文件小。（也就是說雖然all和index都是讀全表，但index是從索引中讀取的，而all是從硬盤中讀的）
   • all：FullTable Scan,將遍歷全表以找到匹配的行

5. possible_keys：顯示可能應用在這張表中的索引,一個或多個。查詢涉及的字段上若存在索引，則該索引將被列出，但不一定被查詢實際使用

6. key：實際使用的索引。如果爲null則沒有使用索引，查詢中若使用了覆蓋索引，則索引和查詢的select字段重疊

7. key_len：表示索引中使用的字節數，可通過該列計算查詢中使用的索引的長度。在不損失精確性的情況下，長度越短越好，key_len顯示的值爲索引最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的

8. ref：顯示索引那一列被使用了，如果可能的話，是一個常數。那些列或常量被用於查找索引列上的值

9. rows：根據表統計信息及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數

10. Extra：包含不適合在其他列中顯示但十分重要的額外信息

    • Using filesort(不好的)：說明mysql會對數據使用一個外部的索引排序，而不是按照表內的索引順序進行讀取。
      MySQL中無法利用索引完成排序操作成爲“文件排序”
    • Using temporary(不好的)：使用了臨時表保存中間結果，MySQL在對查詢結果排序時使用臨時表。常見於排序order by 和分組查詢 group by
    • Using index：表示相應的select操作中使用了覆蓋索引（Coveing Index）,避免訪問了表的數據行，效率不錯！如果同時出現using where，表明索引被用來執行索引鍵值的查找；如果沒有同時出現using where，表面索引用來讀取數據而非執行查找動作。
    • Using where：表面使用了where過濾
    • using join buffer：使用了連接緩存
    • impossible where：where子句的值總是false，不能用來獲取任何元組
    • select tables optimized away：在沒有GROUPBY子句的情況下，基於索引優化MIN/MAX操作或者
      對於MyISAM存儲引擎優化COUNT(*)操作，不必等到執行階段再進行計算，查詢執行計劃生成的階段即完成優化。
    • distinct：優化distinct，在找到第一匹配的元組後即停止找同樣值的工作

2.索引失效

1. 全值匹配我最愛
2. 最佳左前綴法則-如果索引了多例，要遵守最左前綴法則。指的是查詢從索引的最左前列開始並且不跳過索引中的列。（例如複合索引中，第一個索引字段沒被使用，則後面的也不會被使用）
3. 不在索引列上做任何操作（計算、函數、（自動or手動）類型轉換），會導致索引失效而轉向全表掃描
4. 存儲引擎不能使用索引中範圍條件右邊的列
5. 儘量使用覆蓋索引（只訪問索引列的查詢（索引列和查詢列一致）），減少select*
6. mysql在使用不等於（！=或者<>）的時候無法使用索引會導致全表掃描
7. is null,is not null 也無法使用索引
8. like以通配符開頭（’$abc…’）mysql索引失效會變成全表掃描操作
9. 字符串不加單引號索引失效
10. 少用or,用它連接時會索引失效

SQL優化

1.join語句的優化

• 儘可能減少join語句中嵌套循環的總次數，以小表驅動大表，也就是小表join大表
• 保證join語句中被驅動的表的join字段已經被索引
• 無法保證被驅動的表的join字段被索引且內存資源充足的前提下，適當加大 joinBuffer的緩衝池設置

2.like語句的優化

• 可以使用主鍵索引
• 使用覆蓋索引，查詢字段必須是建立覆蓋索引字段
• 當覆蓋索引指向的字段是varchar(380)及380以上的字段時，覆蓋索引會失效！

3.group by關鍵字優化語句優化

• groupby實質是先排序後進行分組，遵照索引建的最佳左前綴
• 當無法使用索引列，增大max_length_for_sort_data參數的設置+增大sort_buffer_size參數的設置
• where高於having,能寫在where限定的條件就不要去having限定了。

總結：

慢查詢日誌

1.查看是否開啓及如何開啓

查看：

SHOW VARIABLES LIKE '%slow_query_log%'

開啓：

set global slow_query_log = 1

查看慢sql的時間閾值：

SHOW VARIABLES LIKE 'long_query_time%';

設置慢sql的時間閾值：

set global long_query_time=3;

使用配置文件如下：

slow_query_log=1;
slow_query_log_file=/var/lib/mysql/slow.log
long_query_time=3;
log_output=FILE

鎖機制

1.表鎖

1. 特點：

   偏向MyISAM存儲引擎，開銷小，加鎖快，無死鎖，鎖定粒度大，發生鎖衝突的概率最高，併發最低

2. 加讀鎖：

   lock table ### read
   

3. .加寫鎖：

   lock table ### write
   

4. 表鎖分析：

   • 如何查看哪些表被鎖了

     show open tables;
     

     通過檢查 table_locks_waited table_locks_immediate 狀態變量來分析系統上的表鎖定：運行

     show status like 'table%'
     

5. 總結：
   
   簡而言之就是讀鎖會阻塞寫，但不會阻塞讀；而寫鎖會把讀和寫阻塞。

2.行鎖

1. 特點

   偏向InnoDB存儲引擎，開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高。InnoDB與MyISAM的最大不同有兩點：一是支持事務（TRANSACTION）;二是採用了行級鎖

2. 事物的隔離級別
   

3. 無索引行鎖升級爲表鎖
   varchar 不用 ’ ’ 導致系統自動轉換類型, 行鎖變表鎖

4. 間隙鎖
   當我們使用範圍條件而不是相等條件檢索數據，並請求共享或排它鎖時，InnoDB會給符合條件的已有數據記錄的索引項加鎖；對於鍵值在條件範圍內但並不存在的記錄叫做“間隙”，InnoDB也會對這個“間隙”加鎖，這種鎖機制就叫間隙鎖。
   危害：在執行過程中通過範圍查找的話，他會鎖定整個範圍內所有的索引鍵值，即使這個鍵值不存在。

5. 如何鎖定一行

   使用 select ** for update；使用之後其他操作會被阻塞，直到鎖定的行會話提交 commit。

6. 優化建議

   • 儘可能讓所有數據檢索都通過索引來完成，避免無索引行鎖升級爲表鎖
   • 合理設計索引，儘量縮小鎖的範圍
   • 儘可能較少檢索條件，避免間隙鎖
   • 儘量控制事務大小，減少鎖定資源量和時間長度
   • 儘可能低級別事務隔離