先看看具體有哪些字段：html
mysql> EXPLAIN SELECT 1;
其實除了以SELECT開頭的查詢語句，其他的DELETE、INSERT、REPLACE以及UPDATE語句前邊均可以加上EXPLAIN這個詞兒，用來查看這些語句的執行計劃mysql
建兩張測試表：web
CREATE TABLE t1 (
id INT NOT NULL AUTO_INCREMENT,
key1 VARCHAR(100),
key2 VARCHAR(100),
key3 VARCHAR(100),
name VARCHAR(100),
PRIMARY KEY (id),
KEY idx_key1 (key1),
KEY idx_key2_key3(key2, key3)
) Engine=InnoDB CHARSET=utf8;
CREATE TABLE t2 (
id INT NOT NULL AUTO_INCREMENT,
key1 VARCHAR(100),
key2 VARCHAR(100),
key3 VARCHAR(100),
name VARCHAR(100),
PRIMARY KEY (id),
KEY idx_key1 (key1),
KEY idx_key2_key3(key2, key3)
) Engine=InnoDB CHARSET=utf8;
兩個變種
explain extended
會在 explain 的基礎上額外提供一些查詢優化的信息。緊隨其後經過 show warnings 命令能夠 獲得優化後的查詢語句，從而看出優化器優化了什麼算法
explain extended SELECT * FROM t1 where key1 = '11';
show warnings;
explain partitions
相比 explain 多了個 partitions 字段，若是查詢是基於分區表的話，會顯示查詢將訪問的分區。sql
EXPLAIN PARTITIONS SELECT * FROM t1 INNER JOIN t2 ON t1.key3 = t2.key3;
table列
這一列表示 explain 的一行正在訪問哪一個表數據庫
mysql> EXPLAIN SELECT * FROM t1;
這個查詢語句只涉及對t1表的單表查詢，因此EXPLAIN輸出中只有一條記錄，其中的table列的值是t1，代表這條記錄是用來講明對t1表的單表訪問。微信
mysql> EXPLAIN SELECT * FROM t1 INNER JOIN t2;
能夠看到這個鏈接查詢的執行計劃中有兩條記錄，這兩條記錄的table列分別是t1和t2，這兩條記錄用來分別說明對t1表和t2表的訪問編輯器
注意：函數
當 from 子句中有子查詢時，table列是
<derivenN>格式，表示當前查詢依賴 id=N 的查詢，因而先執行 id=N 的查詢。當有 union 時，UNION RESULT 的 table 列的值爲<union1,2>，1和2表示參與 union 的 select 行id。oop
id列
id列的編號是 select 的序列號，有幾個 select 就有幾個id，而且id的順序是按 select 出現的順序增加的。
id列越大執行優先級越高，id相同則從上往下執行，id爲NULL最後執行
好比下邊這個查詢中只有一個SELECT關鍵字，因此EXPLAIN的結果中也就只有一條id列爲1的記錄：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 = 'e038f672a8';
對於鏈接查詢來講，一個SELECT關鍵字後邊的FROM子句中能夠跟隨多個表，因此在鏈接查詢的執行計劃中，每一個表都會對應一條記錄，可是這些記錄的id值都是相同的，好比：
mysql> EXPLAIN SELECT * FROM t1 INNER JOIN t2;
能夠看到，上述鏈接查詢中參與鏈接的t1和t2表分別對應一條記錄，可是這兩條記錄對應的id值都是1。
注意：
在鏈接查詢的執行計劃中，每一個表都會對應一條記錄，這些記錄的id列的值是相同的，出如今前邊的表表示驅動表，出如今後邊的表表示被驅動表。因此從上邊的EXPLAIN輸出中咱們能夠看出，查詢優化器準備讓t2表做爲驅動表，讓t1表做爲被驅動表來執行查詢
對於包含子查詢的查詢語句來講，就可能涉及多個SELECT關鍵字，因此在包含子查詢的查詢語句的執行計劃中，每一個SELECT關鍵字都會對應一個惟一的id值，好比這樣：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 IN (SELECT key1 FROM t2) OR key3 = 'a1b6cee57a';
從輸出結果中咱們能夠看到，t1表在外層查詢中，外層查詢有一個獨立的SELECT關鍵字，因此第一條記錄的id值就是1，t2表在子查詢中，子查詢有一個獨立的SELECT關鍵字，因此第二條記錄的id值就是2。
可是這裏你們須要特別注意，查詢優化器可能對涉及子查詢的查詢語句進行重寫，從而轉換爲鏈接查詢。因此若是咱們想知道查詢優化器對某個包含子查詢的語句是否進行了重寫，直接查看執行計劃就行了，好比說：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 IN (SELECT key3 FROM t2 WHERE t1.key1 = 'a1b6cee57a');
能夠看到，雖然咱們的查詢語句是一個子查詢，可是執行計劃中t1和t2表對應的記錄的id值所有是1，這就代表了查詢優化器將子查詢轉換爲了鏈接查詢。
對於包含UNION子句的查詢語句來講，每一個SELECT關鍵字對應一個id值也是沒錯的，不過仍是有點兒特別的東西，比方說下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 UNION SELECT * FROM t2;
UNION子句是爲了把id爲1的查詢和id爲2的查詢的結果集合並起來並去重，因此在內部建立了一個名爲<union1, 2>的臨時表（就是執行計劃第三條記錄的table列的名稱），id爲NULL代表這個臨時表是爲了合併兩個查詢的結果集而建立的。
跟UNION對比起來，UNION ALL就不須要爲最終的結果集進行去重，它只是單純的把多個查詢的結果集中的記錄合併成一個並返回給用戶，因此也就不須要使用臨時表。因此在包含UNION ALL子句的查詢的執行計劃中，就沒有那個id爲NULL的記錄，以下所示：
mysql> EXPLAIN SELECT * FROM t1 UNION ALL SELECT * FROM t2;
select_type列
MySQL每個SELECT關鍵字表明的小查詢都定義了一個稱之爲select_type的屬性，意思是咱們只要知道了某個小查詢的select_type屬性，就知道了這個小查詢在整個大查詢中扮演了一個什麼角色
下面是官方文檔介紹：
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain_select_type
SIMPLE
查詢語句中不包含UNION或者子查詢的查詢都算做是SIMPLE類型，比方說下邊這個單表查詢的select_type的值就是SIMPLE：
mysql> EXPLAIN SELECT * FROM t1;
PRIMARY
對於包含UNION、UNION ALL或者子查詢的大查詢來講，它是由幾個小查詢組成的，其中最左邊的那個查詢的select_type值就是PRIMARY，比方說：
mysql> EXPLAIN SELECT * FROM t1 UNION SELECT * FROM t2;
從結果中能夠看到，最左邊的小查詢SELECT * FROM t1對應的是執行計劃中的第一條記錄，它的select_type值就是PRIMARY。
UNION
對於包含UNION或者UNION ALL的大查詢來講，它是由幾個小查詢組成的，其中除了最左邊的那個小查詢之外，其他的小查詢的select_type值就是UNION，能夠對比上一個例子的效果
UNION RESULT
MySQL選擇使用臨時表來完成UNION查詢的去重工做，針對該臨時表的查詢的select_type就是UNION RESULT，一樣對比上面的例子
SUBQUERY
若是包含子查詢的查詢語句不可以轉爲對應的semi-join的形式，而且該子查詢是不相關子查詢，而且查詢優化器決定採用將該子查詢物化的方案來執行該子查詢時，該子查詢的第一個SELECT關鍵字表明的那個查詢的select_type就是SUBQUERY，好比下邊這個查詢：
概念解釋：
semi-join子查詢，是指當一張表在另外一張表找到匹配的記錄以後，半鏈接（semi-jion）返回第一張表中的記錄。與條件鏈接相反，即便在右節點中找到幾條匹配的記錄，左節點 的表也只會返回一條記錄。另外，右節點的表一條記錄也不會返回。半鏈接一般使用IN 或 EXISTS 做爲鏈接條件
物化：這個將子查詢結果集中的記錄保存到臨時表的過程稱之爲物化（Materialize）。那個存儲子查詢結果集的臨時表稱之爲物化表。正由於物化表中的記錄都創建了索引（基於內存的物化表有哈希索引，基於磁盤的有B+樹索引），經過索引執行IN語句判斷某個操做數在不在子查詢結果集中變得很是快，從而提高了子查詢語句的性能。
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 IN (SELECT key1 FROM t2) OR key3 = 'a1b6cee57a';
能夠看到，外層查詢的select_type就是PRIMARY，子查詢的select_type就是SUBQUERY。
DEPENDENT SUBQUERY
若是包含子查詢的查詢語句不可以轉爲對應的semi-join的形式，而且該子查詢是相關子查詢，則該子查詢的第一個SELECT關鍵字表明的那個查詢的select_type就是DEPENDENT SUBQUERY，好比下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 IN (SELECT key1 FROM t2 WHERE t1.key2 = t2.key2) OR key3 = 'a1b6cee57a';
DEPENDENT UNION
在包含UNION或者UNION ALL的大查詢中，若是各個小查詢都依賴於外層查詢的話，那除了最左邊的那個小查詢以外，其他的小查詢的select_type的值就是DEPENDENT UNION。比方說下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 IN (SELECT key1 FROM t2 WHERE key1 = 'a1b6cee57a' UNION SELECT key1 FROM t1 WHERE key1 = 'a1b6cee57a');
這個查詢比較複雜啊，大查詢裏包含了一個子查詢，子查詢裏又是由UNION連起來的兩個小查詢。從執行計劃中能夠看出來，SELECT key1 FROM t2 WHERE key1 = 'a1b6cee57a'這個小查詢因爲是子查詢中第一個查詢，因此它的select_type是DEPENDENT SUBQUERY，而SELECT key1 FROM t1 WHERE key1 = 'a1b6cee57a'這個查詢的select_type就是DEPENDENT UNION。
DERIVED
對於採用物化的方式執行的包含派生表的查詢，該派生表對應的子查詢的select_type就是DERIVED，比方說下邊這個查詢：
mysql> EXPLAIN SELECT * FROM (SELECT key1, count(*) as t FROM t1 GROUP BY key1) AS derived_t1 where t > 1;
從執行計劃中能夠看出，id爲2的記錄就表明子查詢的執行方式，它的select_type是DERIVED，說明該子查詢是以物化的方式執行的。id爲1的記錄表明外層查詢，你們注意看它的table列顯示的是<derived2>，表示該查詢是針對將派生表物化以後的表進行查詢的。
MATERIALIZED
當查詢優化器在執行包含子查詢的語句時，選擇將子查詢物化以後與外層查詢進行鏈接查詢時，該子查詢對應的select_type屬性就是MATERIALIZED，好比下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 IN (SELECT key1 FROM t2);
執行計劃的第三條記錄的id值爲2，說明該條記錄對應的是一個單表查詢，從它的select_type值爲MATERIALIZED能夠看出，查詢優化器是要把子查詢先轉換成物化表。而後看執行計劃的前兩條記錄的id值都爲1，說明這兩條記錄對應的表進行鏈接查詢，須要注意的是第二條記錄的table列的值是<subquery2>，說明該表其實就是id爲2對應的子查詢執行以後產生的物化表，而後將s1和該物化表進行鏈接查詢。
type列
這一列表示關聯類型或訪問類型，即MySQL決定如何查找表中的行，查找數據行記錄的大概範圍。依次從最優到最差分別爲：system > const > eq_ref > ref > range > index > ALL通常來講，得保證查詢達到range級別，最好達到ref
NULL
mysql可以在優化階段分解查詢語句，在執行階段用不着再訪問表或索引。例如：在索引列中選取最小值，能夠單獨查找索引來完成，不須要在執行時訪問表
mysql> explain select min(id) from t1;
eq_ref
primary key 或 unique key 索引的全部部分被鏈接使用 ，最多隻會返回一條符合條件的記錄。這多是在 const 以外最好的聯接類型了，簡單的 select 查詢不會出現這種 type。
在鏈接查詢時，若是被驅動表是經過主鍵或者惟一二級索引列等值匹配的方式進行訪問的（若是該主鍵或者惟一二級索引是聯合索引的話，全部的索引列都必須進行等值比較），則對該被驅動表的訪問方法就是eq_ref，比方說：
mysql> EXPLAIN SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.id;
從執行計劃的結果中能夠看出，MySQL打算將t2做爲驅動表，t1做爲被驅動表，重點關注t1的訪問方法是eq_ref，代表在訪問t1表的時候能夠經過主鍵的等值匹配來進行訪問。
ref
當經過普通的二級索引列與常量進行等值匹配時來查詢某個表，那麼對該表的訪問方法就多是ref
相比 eq_ref，不使用惟一索引，而是使用普通索引或者惟一性索引的部分前綴，索引要和某個值相比較，可能會找到多個符合條件的行。
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 = 'a';
能夠看到type列的值是ref，代表MySQL即將使用ref訪問方法來執行對t1表的查詢
system，const
mysql能對查詢的某部分進行優化並將其轉化成一個常量（能夠看show warnings 的結果）。用於 primary key 或 unique key 的全部列與常數比較時，因此表最多有一個匹配行，讀取1次，速度比較快。system是const的特例，表裏只有一條元組匹配時爲system
mysql> EXPLAIN SELECT * FROM t1 WHERE id = 5;
ref_or_null
當對普通二級索引進行等值匹配查詢，該索引列的值也能夠是NULL值時，那麼對該表的訪問方法就多是ref_or_null，好比說：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 = 'a' OR key1 IS NULL;
index_merge
通常狀況下對於某個表的查詢只能使用到一個索引，但在某些場景下可使用多種索引合併的方式來執行查詢，咱們看一下執行計劃中是怎麼體現MySQL使用索引合併的方式來對某個表執行查詢的：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 = 'a' OR key2 = 'a';
從執行計劃的type列的值是index_merge就能夠看出，MySQL打算使用索引合併的方式來執行對t1表的查詢。
unique_subquery
相似於兩錶鏈接中被驅動表的eq_ref訪問方法，unique_subquery是針對在一些包含IN子查詢的查詢語句中，若是查詢優化器決定將IN子查詢轉換爲EXISTS子查詢，並且子查詢可使用到主鍵進行等值匹配的話，那麼該子查詢執行計劃的type列的值就是unique_subquery，好比下邊的這個查詢語句：
mysql> EXPLAIN SELECT * FROM t1 WHERE key2 IN (SELECT id FROM t2 where t1.key1 = t2.key1) OR key3 = 'a';
能夠看到執行計劃的第二條記錄的type值就是unique_subquery，說明在執行子查詢時會使用到id列的索引。
range
範圍掃描一般出如今 in(), between ,> ,<, >= 等操做中。使用一個索引來檢索給定範圍的行。
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 IN ('a', 'b', 'c');
index
當咱們可使用索引覆蓋，但須要掃描所有的索引記錄時，該表的訪問方法就是index
掃描全表索引，這一般比ALL快一些。（index是從索引中讀取的，而all是從硬盤中讀取）
ALL
最熟悉的全表掃描
mysql> explain select * from t2;
通常來講，這些訪問方法按照咱們介紹它們的順序性能依次變差。其中除了All這個訪問方法外，其他的訪問方法都能用到索引，除了index_merge訪問方法外，其他的訪問方法都最多隻能用到一個索引。
possible_keys和key列
possible_keys列顯示查詢可能使用哪些索引來查找。
explain 時可能出現 possible_keys 有列，而 key 顯示 NULL 的狀況，這種狀況是由於表中數據很少，mysql認爲索引對此查詢幫助不大，選擇了全表查詢。
若是possible_keys列是NULL，則沒有相關的索引。在這種狀況下，能夠經過檢查 where 子句看是否能夠創造一個適當的索引來提升查詢性能，而後用 explain 查看效果。
key列顯示mysql實際採用哪一個索引來優化對該表的訪問。若是沒有使用索引，則該列是 NULL。若是想強制mysql使用或忽視possible_keys列中的索引，在查詢中使用 force index、ignore index。
比方說下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 > 'z' AND key2 = 'a';
上述執行計劃的possible_keys列的值是idx_key1,idx_key2_key3，表示該查詢可能使用到idx_key1,idx_key2_key3兩個索引，而後key列的值是idx_key3，表示通過查詢優化器計算使用不一樣索引的成本後，最後決定使用idx_key3來執行查詢比較划算。
須要注意的一點是，possible_keys列中的值並非越多越好，可能使用的索引越多，查詢優化器計算查詢成本時就得花費更長時間，因此若是能夠的話，儘可能刪除那些用不到的索引。
key_len列
這一列顯示了mysql在索引裏使用的字節數，經過這個值能夠算出具體使用了索引中的哪些列
對於使用固定長度類型的索引列來講，它實際佔用的存儲空間的最大長度就是該固定值，對於指定字符集的變長類型的索引列來講，好比某個索引列的類型是VARCHAR(100)，使用的字符集是utf8，那麼該列實際佔用的最大存儲空間就是100 × 3 = 300個字節。
若是該索引列能夠存儲NULL值，則key_len比不能夠存儲NULL值時多1個字節。
對於變長字段來講，都會有2個字節的空間來存儲該變長列的實際長度。
當字符串過長時，mysql會作一個相似左前綴索引的處理，將前半部分的字符提取出來作索引。
key_len計算規則以下：字符串 char(n)：n字節長度 varchar(n)：2字節存儲字符串長度，若是是utf-8，則長度 3n + 2 數值類型 tinyint：1字節 smallint：2字節 int：4字節 bigint：8字節 時間類型 date：3字節 timestamp：4字節 datetime：8字節
好比下邊這個查詢：
mysql> EXPLAIN SELECT * FROM s1 WHERE id = 5;
因爲id列的類型是INT，而且不能夠存儲NULL值，因此在使用該列的索引時key_len大小就是4。
對於可變長度的索引列來講，好比下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 = 'a';
因爲key1列的類型是VARCHAR(100)，因此該列實際最多佔用的存儲空間就是300字節，又由於該列容許存儲NULL值，因此key_len須要加1，又由於該列是可變長度列，因此key_len須要加2，因此最後ken_len的值就是303。
rows列
這一列是mysql估計要讀取並檢測的行數，注意這個不是結果集裏的行數。
若是查詢優化器決定使用全表掃描的方式對某個表執行查詢時，執行計劃的rows列就表明預計須要掃描的行數，若是使用索引來執行查詢時，執行計劃的rows列就表明預計掃描的索引記錄行數。好比下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 > 'a';
咱們看到執行計劃的rows列的值是113，這意味着查詢優化器在通過分析使用idx_key1進行查詢的成本以後，以爲知足key1 > 'a'這個條件的記錄只有113條。
ref列
這一列顯示了在key列記錄的索引中，表查找值所用到的列或常量，常見的有：const（常量），字段名（例：t1.id）
ref列展現的就是與索引列做等值匹配的值什麼，好比只是一個常數或者是某個列。你們看下邊這個查詢：
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 = 'a';
能夠看到ref列的值是const，代表在使用idx_key1索引執行查詢時，與key1列做等值匹配的對象是一個常數，固然有時候更復雜一點：
mysql> EXPLAIN SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.id;
能夠看到對被驅動表t1的訪問方法是eq_ref，而對應的ref列的值是canal_manager.t2.id，這說明在對被驅動表進行訪問時會用到PRIMARY索引，也就是聚簇索引與一個列進行等值匹配的條件，於t2表的id做等值匹配的對象就是canal_manager.t2.id列（注意這裏把數據庫名也寫出來了）。
有的時候與索引列進行等值匹配的對象是一個函數，比方說下邊這個查詢
mysql> EXPLAIN SELECT * FROM t1 INNER JOIN t2 ON t2.key1 = UPPER(t1.key1);
咱們看執行計劃的第二條記錄，能夠看到對t2表採用ref訪問方法執行查詢，而後在查詢計劃的ref列裏輸出的是func，說明與t2表的key1列進行等值匹配的對象是一個函數。
Extra列
顧名思義，Extra列是用來講明一些額外信息的，咱們能夠經過這些額外信息來更準確的理解MySQL到底將如何執行給定的查詢語句。
Using index
查詢的列被索引覆蓋，而且where篩選條件是索引的前導列，是性能高的表現。通常是使用了覆蓋索引(索引包含了全部查詢的字段)。對於innodb來講，若是是輔助索引性能會有很多提升
mysql> EXPLAIN SELECT key1 FROM t1 WHERE key1 = 'a';
Using where
當咱們使用全表掃描來執行對某個表的查詢，而且該語句的WHERE子句中有針對該表的搜索條件時，在Extra列中會提示上述額外信息。好比下邊這個查詢
mysql> EXPLAIN SELECT * FROM t1 WHERE name= 'a1b6cee57a';
Using where Using index
查詢的列被索引覆蓋，而且where篩選條件是索引列之一可是不是索引的前導列，意味着沒法直接經過索引查找來查詢到符合條件的數據
mysql> EXPLAIN SELECT id FROM t1 WHERE key3= 'a1b6cee57a';
NULL
查詢的列未被索引覆蓋，而且where篩選條件是索引的前導列，意味着用到了索引，可是部分字段未被索引覆蓋，必須經過「回表」來實現，不是純粹地用到了索引，也不是徹底沒用到索引
mysql> EXPLAIN SELECT * FROM t1 WHERE key2= 'a1b6cee57a';
Using index condition
與Using where相似，查詢的列不徹底被索引覆蓋，where條件中是一個前導列的範圍；
mysql> EXPLAIN SELECT * FROM t1 WHERE key1 like '1';
Using temporary
在許多查詢的執行過程當中，MySQL可能會藉助臨時表來完成一些功能，好比去重、排序之類的，好比咱們在執行許多包含DISTINCT、GROUP BY、UNION等子句的查詢過程當中，若是不能有效利用索引來完成查詢，MySQL頗有可能尋求經過創建內部的臨時表來執行查詢。若是查詢中使用到了內部的臨時表，在執行計劃的Extra列將會顯示Using temporary提示，比方說這樣：
name沒有索引，此時建立了張臨時表來distinct
mysql> explain select distinct name from t1;
key1創建了idx_key1索引，此時查詢時extra是using index,沒有用臨時表
mysql> explain select distinct key1 from t1;
Using filesort
mysql 會對結果使用一個外部索引排序，而不是按索引次序從表裏讀取行。此時mysql會根據聯接類型瀏覽全部符合條件的記錄，並保存排序關鍵字和行指針，而後排序關鍵字並按順序檢索行信息。這種狀況下通常也是要考慮使用索引來優化的。
name未建立索引，會瀏覽t1整個表，保存排序關鍵字name和對應的id，而後排序name並檢索行記錄
mysql> explain select * from t1 order by name;
key1創建了idx_key1索引,此時查詢時extra是using index
mysql> explain select * from t1 order by key1;
Using join buffer (Block Nested Loop)
在鏈接查詢執行過程當中，當被驅動表不能有效的利用索引加快訪問速度，MySQL通常會爲其分配一塊名叫join buffer的內存塊來加快查詢速度，也就是咱們所講的基於塊的嵌套循環算法，好比下邊這個查詢語句：
mysql> EXPLAIN SELECT * FROM t1 INNER JOIN t2 ON t1.key3 = t2.key3;
No tables used
當查詢語句的沒有FROM子句時將會提示該額外信息，好比：
mysql> EXPLAIN SELECT 1;
Impossible WHERE
查詢語句的WHERE子句永遠爲FALSE時將會提示該額外信息，比方說：
mysql> EXPLAIN SELECT * FROM t1 WHERE 1 != 1;
參考：
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-extra-information
掃碼關注
本文分享自微信公衆號 - 月伴飛魚（gh_c4183eee9eb9）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。