Mysql基本架構及查詢流程

mysql體系結構簡單概述:

1. Connectors:接入方,支持協議很多
2. Management Serveices & Utilities：系統管理和控制工具例如：備份恢復，mysql復制集群等
3. Connection Pool：連接池：管理緩沖用戶連接、用戶名、密碼、權限校驗、線程處理等需要緩存的需求
4. SQL Interface：SQL接口：接受用戶的SQL命令，並且返回用戶需要查詢的結果。比如select from就是調用SQL Interface
5. Parser: 解析器，SQL命令傳遞到解析器的時候會被解析器驗證和解析。解析器是由Lex和YACC實現的。
6. Optimizer: 查詢優化器，SQL語句在查詢之前會使用查詢優化器對查詢進行優化
7. Cache和Buffer（高速緩存區）： 查詢緩存，如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取數據。
8. pluggable storage Engines：插件式存儲引擎。存儲引擎是MySql中具體的與文件打交道的子系統。也是Mysql最具有特色的一個地方。 Mysql的存儲引擎是插件式的。
9. file system  ：文件系統，數據、日志（redo，undo）、索引、錯誤日志、查詢記錄、慢查詢等

常見的存儲引擎:

 Mysql插拔式的存儲引擎：

1. 插拔式的插件方式。
2. 存儲引擎是指定在表之上的，即一個庫中的每一個表都可以指定專用的存儲引擎。
3. 不管表采用什么樣的存儲引擎，都會在數據區，產生對應的一個frm文件（表結構定義描述文件）。

CSV：https://dev.mysql.com/doc/refman/5.7/en/csv-storage-engine.html

　　數據存儲以CSV文件，會生成3個文件 table_name.CSM(元數據狀態管理，數據行) table_name.CSV（數據文件） table_name.frm。特點：

　　不能定義沒有索引、列定義必須為NOT NULL。

　　不能設置自增列，不適用大表或者數據的在線處理。

　　CSV數據的存儲用,隔開，可直接編輯CSV文件進行數據的編排，數據安全性低。

注：編輯之后，要生效使用 flush table XXX 命令。

應用場景：數據的快速導出導入，表格直接轉換成CSV。

Archive：https://dev.mysql.com/doc/refman/5.7/en/archive-storage-engine.html

　　會生成 table_name.ARZ   table_name.frm，數據存儲為ARZ文件格式。特點：

　　只支持 insert 和 select 兩種操作，只允許自增ID列建立索引，行級鎖，不支持事務，數據占用磁盤少。

應用場景：日志系統，大量的設備數據采集。

Memory(heap)：https://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html

　　數據都是存儲在內存中，IO效率要比其他引擎高很多，服務重啟數據丟失，內存數據表默認只有16M。特點：

　　支持hash索引，B tree索引，默認hash（查找復雜度0(1)），字段長度都是固定長度varchar(32)=char(32)，不支持大數據存儲類型字段如 blog，text，表級鎖

應用場景：等值查找熱度較高數據，查詢結果內存中的計算，大多數都是采用這種存儲引擎，作為臨時表存儲需計算的數據。

Myisam：https://dev.mysql.com/doc/refman/5.7/en/myisam-storage-engine.html

　　Mysql5.5版本之前的默認存儲引擎，較多的系統表也還是使用這個存儲引擎，系統臨時表也會用到Myisam存儲引擎。特點：

　　select count(*) from table 無需進行數據的掃描，數據（MYD）和索引（MYI）分開存儲，表級鎖，不支持事務。

Innodb：https://dev.mysql.com/doc/refman/5.7/en/innodb-introduction.html

　　在創建好表結構並且指定搜索引擎為 Myisam之后，會在數據目錄生成3個文件，分別是table_name.frm(表結構文件)，table_name.idb（數據與索引保存文件）。Mysql5.5及以后版本的默認存儲引擎

　　Key Advantages：Its DML operations follow the ACID model [事務ACID]。

　　Row-level locking[行級鎖]InnoDB tables arrange your data on disk to optimize queriesbased on primary keys[聚集索引（主鍵索引）方式進行數據存儲]。

　　To maintain data integrity, InnoDB supports FOREIGN KEY constraints[支持外鍵關系保證數據完整性]。

　　接下來看一下這些常用的搜索引擎的簡單對比圖，也能看出為什么InnoDB最后悔脫穎而出：

MySQL運行機理：

　　由下圖可以看出Mysql的執行流程大致分為 5 個階段：

1. mysql 客戶端/服務端通信階段。
2. 查詢緩存階段。
3. 查詢優化處理階段。
4. 查詢執行引擎階段。
5. 返回客戶端階段。

　　我們可以根據執行的流程來看一下在優化的過程中需要注意點什么。

1.mysql 客戶端/服務端通信階段：

Mysql客戶端與服務端的通信方式是“半雙工”的通信方式，通信方式主要分為以下三種：

• 全雙工：雙向通信，發送同時也可以接收
• 半雙工：雙向通信，同時只能接收或者是發送，無法同時做操作
• 單工：只能單一方向傳送

半雙工通信：

　　在任何一個時刻，要么是有服務器向客戶端發送數據，要么是客戶端向服務端發送數據，這兩個動作不能同時發生。所以我們無法也無需將一個消息切成小塊進行傳輸

特點和限制：

　　客戶端一旦開始發送消息，另一端要接收完整個消息才能響應。客戶端一旦開始接收數據沒法停下來發送指令。

mysql 客戶端/服務端通信--查詢狀態

　　有一整套狀態集去管理狀態。對於一個mysql連接，或者說一個線程，時刻都有一個狀態來標識這個連接正在做什么。查看命令 show full processlist / show processlist

　　

　　要了解狀態的全過程請登錄：https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html (狀態全集)。以下是常見的狀態集：

• Sleep：線程正在等待客戶端發送數據
• Query：連接線程正在執行查詢
• Locked：線程正在等待表鎖的釋放
• Sorting result：線程正在對結果進行排序
• Sending data：向請求端返回數據

　　異常情況下可通過kill {id}的方式進行連接的殺掉

2.查詢緩存階段：

　　工作原理：緩存SELECT操作的結果集和SQL語句；新的SELECT語句，先去查詢緩存，判斷是否存在可用的記錄集。

　　判斷標准：與緩存的SQL語句，是否完全一樣，區分大小寫 (簡單認為存儲了一個key-value結構，key為sql，value為sql查詢結果集)。

　　可以通過以下命令來查看緩存的設置情況：

在my.cnf配置文件中可以配置：

query_cache_type：

• 值：0 -– 不啟用查詢緩存，默認值；
• 值：1 -– 啟用查詢緩存，只要符合查詢緩存的要求，客戶端的查詢語句和記錄集都可以緩存起來，供其他客戶端使用，加上 SQL_NO_CACHE將不緩存 ，如select SQL_NO_CACHE *from.......
• 值：2 -– 啟用查詢緩存，只要查詢語句中添加了參數：SQL_CACHE，且符合查詢緩存的要求，客戶端的查詢語句和記錄集，則可以緩存起來，供其他客戶端使用

query_cache_size：允許設置query_cache_size的值最小為40K，默認1M，推薦設置 為：64M/128M；

query_cache_limit：限制查詢緩存區最大能緩存的查詢記錄集，默認設置為1M

　　可以通過 show status like 'Qcache%' 命令可查看緩存情況：

 

　　需要注意的是，一旦表數據發生一點變化，與這個表所相關的緩存全部失效，不會緩存的情況：

1. 當查詢語句中有一些不確定的數據時，則不會被緩存。如包含函數NOW()，SQL_NO_CACHE，CURRENT_DATE()等類似的函數，或者用戶自定義的函數，存儲函數，用戶變量等都不會被緩存。
2. 當查詢的結果大於query_cache_limit設置的值時，結果不會被緩存。
3. 對於InnoDB引擎來說，當一個語句在事務中修改了某個表，那么在這個事務提交之前，所有與這個表相關的查詢都無法被緩存。因此長時間執行事務，會大大降低緩存命中率。
4. 查詢的表是系統表。
5. 查詢語句不涉及到表。

為什么mysql默認關閉了緩存開啟？？

1. 在查詢之前必須先檢查是否命中緩存,浪費計算資源。
2. 如果這個查詢可以被緩存，那么執行完成后，MySQL發現查詢緩存中沒有這個查詢，則會將結果存入查詢緩存，這會帶來額外的系統消耗。
3. 針對表進行寫入或更新數據時，將對應表的所有緩存都設置失效。
4. 如果查詢緩存很大或者碎片很多時，這個操作可能帶來很大的系統消耗。

適用場景 ：以讀為主的業務，數據生成之后就不常改變的業務。比如門戶類、新聞類、報表類、論壇類等

3.查詢優化處理階段：

　　查詢優化處理的三個階段：

• 解析sql：通過lex詞法分析,yacc語法分析將sql語句解析成解析樹 https://www.ibm.com/developerworks/cn/linux/sdk/lex/。
• 預處理階段：根據mysql的語法的規則進一步檢查解析樹的合法性，如：檢查數據的表和列是否存在，解析名字和別名的設置。還會進行權限的驗證。
• 查詢優化器：優化器的主要作用就是找到最優的執行計划。

　　查詢優化器如何找到最優計划 ，通過explain  +查詢sql查看執行計划+\G。

　　查詢優化器如何找到最優執行計划，有如下規則：

1. 使用等價變化規則：5 = 5 and a > 5 改寫成 a > 5，a < b and a = 5 改寫成 b > 5 and a = 5
2. 基於聯合索引，調整條件位置等
3. 優化count 、min、max等函數：min函數只需找索引最左邊，max函數只需找索引最右邊，myisam引擎count(*)
4. 覆蓋索引掃描：如果是建立了一個 name 字段的索引，InnoDB由於葉子節點保存了ID索引的key值，這種情況下 使用 select id，name from。。。這個也會用到覆蓋索引
5. 子查詢優化　　
6. 提前終止查詢：用了limit關鍵字或者使用不存在的條件，選擇不同的索引來執行，在采用limit的情況下，查詢優化器在成本計算的過程中也可以選擇離散型不高的列索引。
7. IN的優化：用 or的情況是一條一條去比對，in：用二分法，where in(1,2,3,4,5),先排序條件后再比對中間位置 3，通過二分查找法進行查找，當條件多的情況下  ，相對來說的話in的優化會好一點。先進性排序，再采用二分查找的方式

　　Mysql的查詢優化器是基於成本計算的原則。他會嘗試各種執行計划。數據抽樣的方式進行試驗（隨機的讀取一個4K的數據塊進行分析）。

　　mysql查詢優化 -執行計划：使用命令查看一句查詢SQL，看看查詢計划中都涉及什么有用的信息

id：select查詢的序列號，標識執行的順序

• id相同，執行順序由上至下，聯表查詢使用union  id為空。
• id不同，如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行
• id相同又不同即兩種情況同時存在，id如果相同，可以認為是一組，從上往下順序執行；在所有組中，id值越大，優先級越高，越先執行

select_type:查詢的類型，主要是用於區分普通查詢、聯合查詢、子查詢等

• SIMPLE：簡單的select查詢，查詢中不包含子查詢或者union
• PRIMARY：查詢中包含子部分，最外層查詢則被標記為primary
• SUBQUERY/MATERIALIZED：SUBQUERY表示在select 或 where列表中包含了子查詢
• MATERIALIZED表示where 后面in條件的子查詢
• UNION：若第二個select出現在union之后，則被標記為union；
• UNION RESULT：從union表獲取結果的select

table ：查詢涉及到的表

• 直接顯示表名或者表的別名
• <unionM,N> 由ID為M,N 查詢union產生的結果
• <subqueryN> 由ID為N查詢生產的結果

type：訪問類型，sql查詢優化中一個很重要的指標，結果值從好到壞依次是：system > const > eq_ref > ref > range > index > ALL

• system：表只有一行記錄（等於系統表），const類型的特例，基本不會出現，可以忽略不計
• const：表示通過索引一次就找到了，const用於比較primary key 或者 unique索引
• eq_ref：唯一索引掃描，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵 或 唯一索引掃描
• ref：非唯一性索引掃描，返回匹配某個單獨值的所有行，本質是也是一種索引訪問
• range：只檢索給定范圍的行，使用一個索引來選擇行（至少要這個級別）
• index：Full Index Scan，索引全表掃描，把索引從頭到尾掃一遍
• ALL：Full Table Scan，遍歷全表以找到匹配的行

執行計划：

possible_keys：查詢過程中有可能用到的索引

key：實際使用的索引，如果為NULL，則沒有使用索引 rows，根據表統計信息或者索引選用情況，大致估算出找到所需的記錄所需要讀取的行數。

filtered：它指返回結果的行占需要讀到的行(rows列的值)的百分比。表示返回結果的行數占需讀取行數的百分比，filtered的值越大越好。

Extra ：十分重要的額外信息

• Using filesort ：mysql對數據使用一個外部的文件內容進行了排序，而不是按照表內的索引進行排序讀取 order by xxx desc這樣子的，如果是索引字段的排序則不是這樣的，就不需要使用外部文件了
• Using temporary：使用臨時表保存中間結果，也就是說mysql在對查詢結果排序時使用了臨時表，常見於order by 或 group by
• Using index：表示相應的select操作中使用了覆蓋索引（Covering Index），避免了訪問表的數據行，效率高
• Using where ：使用了where過濾條件
• select tables optimized away：基於索引優化MIN/MAX操作或者MyISAM存儲引擎優化COUNT(*)操作，不必等到執行階段在進行計算，查詢執行。計划生成的階段即可完成優化

4.mysql查詢執行引擎階段：

　　調用插件式的存儲引擎的原子API的功能進行執行計划的執行，執行計划的好壞也是依賴於搜索引擎的。

5.返回客戶端階段：

1、有需要做緩存的，執行緩存操作。

2、增量的返回結果：開始生成第一條結果時,mysql就開始往請求方逐步返回數據。

　　好處： mysql服務器無須保存過多的數據，浪費內存。用戶體驗好，馬上就拿到了數據。

如何定位慢SQL：

1. 業務驅動：根據業務反饋來確定哪些sql可能出現問題。
2. 測試驅動：通過測試確定哪些sql出現問題。
3. 慢查詢日志：通過日志記錄的方式查找執行效率慢的sql。
4. 其他第三方工具。

慢日志查詢配置：

show variables like 'slow_query_log' //--查看是否開啟慢日志保存
set global slow_query_log = on //-- 打開慢日志
set global slow_query_log_file = '/var/lib/mysql/gupaoedu-slow.log' //--慢日志保存位置
set global log_queries_not_using_indexes = on //-- 沒有命中索引的是否要記錄慢日志
set global long_query_time = 0.1 (秒) //-- 執行時間超過多少為慢日志

　　可以直接打開編輯 vi slow.log文件來查看，如下圖的信息:

• Time ：日志記錄的時間。
• User@Host：執行的用戶及主機。
• Query_time：查詢耗費時間 Lock_time 鎖表時間 Rows_sent 發送給請求方的記錄，條數 Rows_examined 語句掃描的記錄條數。
• SET timestamp 語句執行的時間點。
• select .... 執行的具體語句。

慢日志分析工具：

　　mysqldumpslow -t(查詢多少行) 10 -s at(平均查詢時間) /var/lib/mysql/gupaoedu-slow.log

 　　通過返回的記錄能看到前10條執行效率比較低下的sql信息，開發者可以通過這些信息去做相應的優化。