Mysql 高級

1 MySQL 的架構介紹

1.1 sql_mode

sql_mode 是一個容易忽視的變量，默認狀況下爲空，能夠忍耐一些非法操做，在生產環境中，必須將其設置爲嚴格模式，在開發測試環境中配該變量也是頗有必要的，由於這樣能夠在生產以前發現問題。

sql_mode 經常使用值以下：

• ONLY_FULL_GROUP_BY：對於 GROUP BY 聚合操做，若是在 SELECT 中的列沒有在 GROUP BY 中出現，那麼這個 sql 是不合法的
• NO_AUTO_VALUE_ON_ZERO：該值影響自增列的插入，默認狀況下，插入 0 或 NULL 表明生成下一個增加值，若是用戶但願插入的主鍵 ID 爲0，就能夠配置這個值
• STRICT_TRANS_TABLES：若是一個值不能插入到一個事務表中，則中斷當前的操做，非事務表不限制
• NO_ZERO_IN_DATE：在嚴格模式下，不容許日期和月份爲零
• NO_ZERO_DATE：不容許插入零日期，不然拋出異常
• ERROR_FOR_DIVISION_BY_ZERO：在插入或更新過程當中，若是數據被零除，則產生錯誤，若是未配置該參數，那麼數據被零除時返回 NULL
• NO_AUTO_CREATE_USER：禁止建立密碼爲空的用戶
• NO_ENGINE_SUBSTITUTION：若是須要的存儲引擎未編譯或被禁用，則拋出錯誤
• PIPES_AS_CONCAT：將 || 視爲字符串鏈接操做符
• ANSI_QUOTES：配置該參數後，不能用 「」 引用字符串

1.2 MySQL 邏輯架構

和其它數據庫相比，MySQL 有點不同凡響，它的架構能夠在多種不一樣場景中應用併發揮良好做用，主要體如今存儲引擎的架構上，插件式的存儲引擎架構將查詢處理和其它的系統任務以及數據的存儲提取相分離，這種架構能夠根據業務的需求和實際須要選擇合適的存儲引擎。

鏈接層

最上層是客戶端和鏈接服務，包含本地 socket 通訊和 tcp/ip 通訊，主要完成鏈接處理、受權認證及相關的安全方案，該層引入了線程池，爲受權用戶提供線程，還實現了 ssl 安全連接。

服務層

• Management Serveices & Utilities：系統管理和控制工具
• SQL Interface：SQL 接口，接收 SQL 命令，並返回查詢結果
• Parser：解析器，對 SQL 命令進行驗證和解析
• Optimizer：查詢優化器，在查詢以前對語句進行優化
• Cache 和 Buffer：查詢緩存，若是查詢緩存有命中的查詢結果，查詢語句就能夠直接去查詢緩存中取數據，這個緩存機制是由一系列小緩存組成的，好比表緩存，記錄緩存，key緩存，權限緩存等

引擎層

存儲引擎層，負責了數據的存儲和提取，服務器經過 API 與存儲引擎進行通訊。

存儲層

數據存儲層，主要是將數據存儲在運行於裸設備的文件系統之上，並完成與存儲引擎的交互。

1.2.1 SQL 的執行週期

開啓診斷分析工具

set profiling=1;

顯示最近的幾條查詢

show profiles;

查看 SQL 的執行步驟

show profile cpu,block io for query 1;

1.2.2 查詢流程

• 客戶端和 MySQL 創建鏈接，發送查詢語句，先查詢緩存，若是緩存有命中，直接返回結果，不然進行語句解析
• 也就是說，解析以前先訪問緩存，解析器將對語句進行語法規則校驗和解析查詢，而後會生成一顆解析樹
• 以後由優化器將解析器轉換成執行計劃，最後執行計劃，返回結果

1.2.3 SQL 執行順序

FROM <left_table>
ON <join_condition>
<join_type> JOIN <right_table>
WHERE <where__condition>
GROUP BY<group_by_list>
HAVING <having__condition>
SELECT
DISTINCT <select_list>
ORDER BY <order_by__condition>
LIMIT <limit_number>

1.3 MySQL 存儲引擎

查看支持的存儲引擎

show engines;

查看當前默認的存儲引擎

show variables like '%storage_engine%';

1.3.1 各個引擎簡介

InnoDB

InnoDB 是 MySQL 默認的事務型引擎，用來處理大量的短時間事務，除非有特別的緣由須要用到其餘存儲引擎，不然優先考慮 InnoDB。

MyISAM

MyISAM 提供了大量的特性，包括全文檢索、壓縮、空間函數等，但 MyISAM 不支持事務和行級鎖，缺點是崩潰後沒法安全恢復。

Archive

Archive 檔案存儲引擎只支持 INSERT 和 SELECT 操做，在 MySQL5.1 以前不支持索引；

Archive 表適合日誌和數據採集類應用；

根據英文的測試結論來看，Archive 表比 MyISAM 表要小大約 75%，比支持事務處理的 InnoDB 表小大約 83%。

Blackhole

Blackhole 引擎沒有實現任何存儲機制，它會丟棄全部插入的數據，不作任何保存。但服務器會記錄Blackhole表的日誌，因此能夠用於複製數據到備庫，或者簡單地記錄到日誌。但這種應用方式會碰到不少問題，所以並不推薦。

CSV

CSV 引擎能夠將普通的 CSV 文件做爲 MySQL 表來處理，但不支持索引， CSV 能夠做爲一種數據交換的機制，CSV 引擎存儲的數據能夠被文本編輯器、execl 讀取。

Memory

若是須要快速地訪問數據，而且這些數據不會被修改，重啓之後丟失也沒有關係，那麼使用Memory表是很是有用，Memory 表至少比 MyISAM 表要快一個數量級。

Federated

Federated 引擎是訪問其餘 MySQL 服務器的一個代理，儘管該引擎看起來提供了一種很好的跨服務器的靈活性，但也常常帶來問題，所以默認是禁用的。

1.3.2 InnoDB 和 MyISAM

對比項	InnoDB	MyISAM
外鍵	支持	不支持
事務	支持	不支持
行表鎖	行鎖，操做時只鎖定操做的那一行，不會對其餘行產生影響，適合於高併發	表鎖，即便只操做一行也會鎖定整個表，不適合高併發
緩存	不只緩存索引還要緩存真實數據，對內存要求較高，並且內存大小對性能有決定性的影響	只緩存索引，不緩存真實數據
關注點	併發寫、事務、更大資源	節省資源、消耗少、簡單業務
默認安裝	Y	Y
默認使用	Y	N
自帶系統表使用	N	Y

2 索引優化分析

2.1 優化步驟

分庫分表

SQL 優化

創建索引

調整 my.cnf 優化服務器及配置參數

2.2 索引簡介

2.2.1 什麼是索引？

數據自己以外，數據庫還維護着一個知足特定查找算法的數據結構，這些數據結構以某種方式指向數據，這樣就能夠在這些數據結構的基礎上實現高級查找算法，這種數據結構就是索引；

通常來講索引自己也很大，不可能所有存儲在內存中，所以索引每每以索引文件的形式存儲的磁盤上；

雖然索引提升了查詢的效率，可是也下降了更新的效率，由於更新表時，不只要插入數據，同時還要保存一下索引文件每次更新添加了的索引列的字段，都會調整由於更新所帶來的鍵值變化後的索引信息；

實際上索引也是一張表，該表保存了主鍵與索引字段，並指向實體表的記錄，因此索引列也是要佔用空間的。

2.2.2 MySQL 索引結構

2.2.2.1 BTree 索引

如圖所示，磁盤塊 1 包含數據項 17 和 35，包含指針 P一、P二、P3

P1 表示小於 17 的磁盤塊，P2 表示介於 17 和 35 之間的磁盤塊，35 表示大於 35 的磁盤塊

查找過程

若是要查找數據項 29，首先將磁盤塊 1 加載到內存，此時發生一次 IO，利用二分查找肯定 29 在 17 和 35 之間，鎖定磁盤塊 1 的 P2 指針，經過磁盤塊 1 的 P2 指針的磁盤地址把磁盤塊 3 加載到內存，此時發生一次 IO，利用二分查找肯定 29 在26 和 30 之間，鎖定磁盤塊 3 的 P2 指針，經過磁盤塊 3 的 P2 指針的磁盤地址把磁盤塊 8 加載到內存，此時發生一次 IO，同時利用二分查找到 29，查詢結束。

2.2.2.2 B+Tree 索引

B+ 樹的非葉子節點只是存儲 key，佔用空間很是小，所以每一層的節點能索引到的數據範圍更加的廣，換句話說，每次 IO 操做能夠觀看更多的數據；

葉子節點兩兩相連，符合磁盤的預讀特性。如圖存儲 五、8 、9 的葉子節點，它有個指針指向了 十、1五、18 這個葉子節點，那麼當咱們從磁盤讀取五、八、9 對應的數據的時候，因爲磁盤的預讀特性，會順便把 十、1五、18 對應的數據讀取出來，這個時候屬於順序讀取，而不是磁盤尋道了，加快了速度；

支持範圍查詢，並且部分範圍查詢很是高效，緣由是數據都是存儲在葉子節點這一層，而且有指針指向其餘葉子節點，這樣範圍查詢只須要遍歷葉子節點這一層，無需整棵樹遍歷。

2.2.2.3 聚簇索引與非聚簇索引

聚簇索引並非一種單獨的索引類型，而是一種數據存儲方式，聚簇表示數據行和相鄰的鍵值聚簇的存儲在一塊兒；

按照聚簇索引排列順序，查詢顯示必定範圍數據的時候，因爲數據都是緊密相連，數據庫不不用從多個數據塊中提取數據，因此節省了大量的 IO 操做；

對於 MySQL 數據庫目前只有 InnoDB 數據引擎支持聚簇索引，而 MyISAM 並不支持聚簇索引；

因爲數據物理存儲排序方式只能有一種，因此每一個 MySQL 的表只能有一個聚簇索引，通常狀況下就是該表的主鍵；

爲了充分利用聚簇索引的聚簇的特性，因此 InnoDB 表的主鍵列儘可能選用有序的順序 ID，而不建議用無序的 ID，好比 UUID這種。

2.2.3 MySQL 索引分類

2.2.2.3.1 單值索引

即一個索引只包含單個列，一個表能夠有多個單列索引

隨表一塊兒建索引： 
CREATE TABLE customer (
    id INT (10) UNSIGNED AUTO_INCREMENT,
    customer_no VARCHAR (200),
    customer_name VARCHAR (200),
    PRIMARY KEY (id),
    KEY (customer_name)
);

單獨建單值索引： 
CREATE INDEX idx_customer_name ON customer (customer_name);

刪除索引： 
DROP INDEX idx_customer_name ON customer;

2.2.3.2 惟一索引

索引列的值必須惟一，但能夠爲空

隨表一塊兒建索引： 
CREATE TABLE customer (
    id INT (10) UNSIGNED AUTO_INCREMENT,
    customer_no VARCHAR (200),
    customer_name VARCHAR (200),
    PRIMARY KEY (id),
    KEY (customer_name),
    UNIQUE (customer_no)
);

單獨建惟一索引： 
CREATE UNIQUE INDEX idx_customer_no ON customer (customer_no);

刪除索引： 
DROP INDEX idx_customer_no ON customer;

2.2.3.3 主鍵索引

設爲主鍵後自動建立主鍵索引

隨表一塊兒建索引： 
CREATE TABLE customer (
    id INT (10) UNSIGNED AUTO_INCREMENT,
    customer_no VARCHAR (200),
    customer_name VARCHAR (200),
    PRIMARY KEY (id)
);

單獨建主鍵索引： 
ALTER TABLE customer ADD PRIMARY KEY customer (customer_no);

刪除建主鍵索引： 
ALTER TABLE customer DROP PRIMARY KEY;

修改建主鍵索引： 必須先刪除掉 (DROP) 原索引，再新建 (ADD) 索引

2.2.3.4 複合索引

一個索引包含單個列

隨表一塊兒建索引： 
CREATE TABLE customer (
    id INT (10) UNSIGNED AUTO_INCREMENT,
    customer_no VARCHAR (200),
    customer_name VARCHAR (200),
    PRIMARY KEY (id),
    KEY (customer_name),
    UNIQUE (customer_name),
    KEY (customer_no, customer_name)
);

單獨建索引： 
CREATE INDEX idx_no_name ON customer (customer_no, customer_name);

刪除索引： 
DROP INDEX idx_no_name ON customer;

2.2.4 建立索引的時機

哪些狀況須要建立索引？

• 主鍵自動建立惟一索引
• 頻繁做爲查詢條件的字段應該建立索引
• 查詢中與其餘表關聯的字段，外鍵關係創建索引
• 組合索引比單值索引性價比更高
• 查詢排序的字段，排序字段若經過索引去訪問將大大提升排序速度
• 查詢中統計或分組字段

哪些狀況不須要建立索引？

• 表記錄太少
• 常常更新的表
• where 條件裏用不到的字段不須要建立索引
• 過濾性很差的字段不須要建立索引

2.3 性能分析

2.3.1 EXPLAN

使用 EXPLAIN 關鍵字能夠模擬優化器執行 SQL 查詢語句，從而知道 MySQL 是如何處理 SQL 語句的，分析查詢語句或是表結構的性能瓶頸。

EXPLAN 的做用：

查看錶的讀取順序

查看哪些索引能夠被使用

數據讀取操做的操做類型

哪些索引被實際使用

表之間的引用

使用方式：

Explain + SQL

Explain SELECT * FROM t_emp A LEFT JOIN t_dept B ON A.deptId = B.id WHERE B.`id` IS NULL
    -> UNION
    -> SELECT * FROM t_emp A RIGHT JOIN t_dept B ON A.deptId = B.id WHERE A.`deptId` IS NULL;

2.3.2 各字段解釋

• id：

  SELECT 查詢的序列號,包含一組數字，表示查詢中執行 SELECT 子句或操做表的順序

  • id 相同：執行順序由上至下

  • id 不一樣：若是是子查詢，id 的序號會遞增，id 值越大優先級越高，越先被執行

  • id 相同不一樣，同時存在：id若是相同，能夠認爲是一組，從上往下順序執行；在全部組中，id值越大，優先級越高，越先執行

  每一個 id 表示一趟獨立的查詢，一個 SQL 的查詢趟數越少越好

• select_type

  查詢的類型，主要是用於區別普通查詢、聯合查詢、子查詢等的複雜查詢

  • SIMPLE：最簡單的查詢，不包含 UNION 和子查詢

  • PRIMARY：查詢中若包含複雜的子部分，最外層查詢被標記爲 PRIMARY

  • DERIVED：在 FROM 列表中包含的子查詢被標記爲 DERIVED，MySQL 會遞歸執行這些子查詢, 把結果放在臨時表裏

  • SUBQUERY：在 SELECT 或 WHERE 列表中包含子查詢

  • DEPENDENT SUB：在 SELECT 或 WHERE 列表中包含子查詢，子查詢基於外層

  • UNCACHEABLE SUBQUREY：結果集不能被緩存的子查詢，必須從新爲外層查詢的每一行進行評估

  • UNION：若第二個 SELECT 出如今 UNION 以後，則被標記爲 UNION

  • UNION RESULT：從 UNION 表獲取結果的 SELECT

• table

  顯示這一行的數據是關於哪張表的

• type

  顯示鏈接使用的類型，按最優到最差的類型排序

  • system：表只有一行記錄

  • const：表示經過索引一次就找到了，const 用於比較 primary key 或者 unique 索引，由於只匹配一行數據，因此很快
    如將主鍵置於 where 列表中，MySQL 就能將該查詢轉換爲一個常量

  • eq_ref：惟一性索引掃描，對於每一個索引鍵，表中只有一條記錄與之匹配，常見於主鍵或惟一索引掃描

  • ref：非惟一性索引掃描，返回匹配某個單獨值的全部行，本質上也是一種索引訪問，它返回全部匹配某個單獨值的行，然而，它可能會找到多個符合條件的行，因此它應該屬於查找和掃描的混合體

  • range：只檢索給定範圍的行，使用一個索引來選擇行，key 列顯示使用了哪一個索引，通常就是在 where 語句中出現了 between、<、>、in 等的查詢，這種範圍掃描索引掃描比全表掃描要好，由於它只須要開始於索引的某一點，而結束語另外一點，不用掃描所有索引

  • index：出現 index 是 SQL 使用了索引可是沒用經過索引進行過濾，通常是使用了覆蓋索引或者是利用索引進行了排序分組

  • all：Full Table Scan，將遍歷全表以找到匹配的行

  • index_merge：在查詢過程當中須要多個索引組合使用，一般出如今有 or 的關鍵字的 SQL 中

  • ref_or_null：對於某個字段既須要關聯條件，也須要 null 值的狀況下，查詢優化器會選擇用 ref_or_null 鏈接查詢

  • index_subquery：利用索引來關聯子查詢，再也不全表掃描

  • unique_subquery：該聯接類型相似於 index_subquery，子查詢中的惟一索引

  通常來講，得保證查詢至少達到 range 級別，最好能達到 ref

• possible_keys

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

• key

  實際使用的索引，若是爲NULL，則沒有使用索引，查詢中若使用了覆蓋索引，則該索引和查詢的 select 字段重疊

• key_len

  表示索引中使用的字節數，可經過該列計算查詢中使用的索引的長度， key_len 字段可以檢查是否充分的利用上了索引

• ref

  顯示索引的哪一列被使用了，若是可能的話，是一個常數，哪些列或常量被用於查找索引列上的值

• rows

  rows 列顯示 MySQL 認爲它執行查詢時必須檢查的行數

• Extra

  包含不適合在其餘列中顯示但十分重要的額外信息

  • Using filesort：說明 mysql 會對數據使用一個外部的索引排序，而不是按照表內的索引順序進行讀取，MySQL 中沒法利用索引完成的排序操做稱爲文件排序
  • Using temporary：使了用臨時表保存中間結果，MySQL 在對查詢結果排序時使用臨時表，常見於排序 order by 和分組查詢 group by
  • USING index：表示相應的 select 操做中使用了覆蓋索引(Covering Index)，避免訪問了表的數據行，效率不錯，若是同時出現 using where，代表索引被用來執行索引鍵值的查找，若是沒有同時出現 using where，代表索引只是用來讀取數據而非利用索引執行查找
  • Using where：代表使用了 where 過濾
  • using join buffer：使用了鏈接緩存：
  • impossible where：where 子句的值老是 false，不能用來獲取任何元組
  • select tables optimized away：在沒有 GROUP BY 子句的狀況下，基於索引優化 MIN/MAX 操做或者對於MyISAM 存儲引擎優化 COUNT(*) 操做，沒必要等到執行階段再進行計算，查詢執行計劃生成的階段即完成優化。

2.4 查詢優化

2.4.1 單表使用索引失效問題

index(a,b,c)

Where語句	索引是否被使用
WHERE a = 3	y，使用到 a
WHERE a = 3 AND b = 5	y，使用到 a、b
WHERE a = 3 AND b = 5 AND c = 4	y，使用到 a、b、c
WHERE b = 三、WHERE b = 3 AND c = 四、WHERE c = 4	n
WHERE a = 3 AND c = 5	y，使用到 a，b中斷了
WHERE a = 3 AND b > 4 AND c = 5	y，使用到 a，b 中斷了
WHERE a IS NULL AND b IS NOT NULL	is null 支持索引 可是is not null 不支持，因此 a 可使用索引，b 不可使用索引
WHERE a <> 3	<> 不能使用索引
WHERE abs(a) = 3	abs 不能使用索引
WHERE a = 3 AND b LIKE 'kk%' AND c = 4	y，使用到 a、b、c
WHERE a = 3 AND b LIKE '%kk' AND c = 4	y，使用到 a
WHERE a = 3 AND b LIKE '%kk%' AND c = 4	y，使用到 a
WHERE a = 3 AND b LIKE 'k%kk%' AND c = 4	y，使用到 a、b、c

建立索引的建議：

對於單值索引，儘可能選擇針對當前查詢過濾性更高的字段

選擇組合索引，當前查詢過濾性最高的字段在索引的位置越靠前越好

選擇組合索引，儘可能選擇能夠可以包含當前查詢中的 where 字句中更多字段的索引

在選擇組合索引的時候，若是某個字段可能出現範圍查詢時，儘可能把這個字段放在索引次序的最後面

2.4.2 關聯查詢優化

保證被驅動表的 join 字段已經被索引

left join 時，選擇小表做爲驅動表，大表做爲被驅動表

inner join 時，MySQL 會本身把小結果集的表選爲驅動表

子查詢儘可能不要放在被驅動表，有可能使用不到索引

可以直接多表關聯的儘可能直接關聯，不用子查詢

2.4.3 子查詢優化

儘可能不要使用not in 或者 not exists，用 left join on xxx is null 替代

2.4.4 排序分組優化

ORDER BY子句，儘可能使用Index方式排序,避免使用FileSort方式排序

若是不在索引列上，filesort 有兩種算法：

雙路排序

• MySQL 4.1 以前是使用雙路排序,字面意思就是兩次掃描磁盤，最終獲得數據，讀取行指針和 order by 列，對他們進行排序，而後掃描已經排序好的列表，按照列表中的值從新從列表中讀取對應的數據輸出
• 從磁盤取排序字段，在 buffer 進行排序，再從磁盤取其餘字段
• 取一批數據，要對磁盤進行了兩次掃描，衆所周知，IO 是很耗時的，因此在 MySQL 4.1 以後，出現了第二種改進的算法，就是單路排序

單路排序：

• 從磁盤讀取查詢須要的全部列，按照 order by 列在 buffer 對它們進行排序，而後掃描排序後的列表進行輸出，它的效率更快一些，避免了第二次讀取數據，而且把隨機 IO 變成了順序 IO，可是它會使用更多的空間，由於它把每一行都保存在內存中了
• 單路排序是把全部的字段都取出，因此有可能取出的數據的總大小超過了 sort_buffer 的容量，致使每次只能取 sort_buffer 容量大小的數據進行排序，排序完再取一部分，反而增大了 IO
• 優化策略
  • 增大sort_buffer_size參數的設置
  • 增大max_length_for_sort_data參數的設置
  • 減小 select 後面的查詢的字段
  • 禁止使用 select *

group by 使用索引的原則幾乎跟 order by 一致 ，惟一區別是 group by 即便沒有過濾條件用到索引，也能夠直接使用索引

3 查詢截取分析

什麼是慢查詢日誌？

慢查詢日誌是 MySQL 提供的一種日誌記錄，它用來記錄在 MySQL 中響應時間超過閾值的語句，具體指運行時間超過long_query_time 值的 SQL，則會被記錄到慢查詢日誌中；

long_query_time 的默認值爲10，意思是運行10秒以上的語句。

默認慢查詢日誌是關閉的，須要手動開啓

查看慢查詢日誌是否開啓
SHOW VARIABLES LIKE '%slow_query_log%';
開啓慢查詢日誌
set global slow_query_log=1;

查看並配置 long_query_time

查看long_query_time
SHOW VARIABLES LIKE 'long_query_time%';
set  long_query_time=1

日誌分析工具 mysqldumpslow

經常使用參考：

hadoop100獲得返回記錄集最多的10個SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/hadoop100-slow.log

獲得訪問次數最多的10個SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/hadoop100-slow.log

獲得按照時間排序的前10條裏面含有左鏈接的查詢語句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/hadoop100-slow.log

另外建議在使用這些命令時結合 | 和more 使用 ，不然有可能出現爆屏狀況
mysqldumpslow -s r -t 10 /var/lib/mysql/hadoop100-slow.log | more

4 主從複製

複製的基本原理

master 將改變記錄到二進制日誌（binary log），這些記錄過程叫作二進制日誌事件，binary log events；

slave 將 master 的 binary log events 拷貝到它的中繼日誌（relay log）；

slave 重作中繼日誌中的事件，將改變應用到本身的數據庫中，MySQL 複製是異步的且串行化的。

複製的基本原則

每一個 slave 只有一個 master

每一個 slave 只能有一個惟一的服務器 ID

每一個 master 能夠有多個salve

4.1 配置主從複製

一、配置主數據庫

vim /etc/my.cnf

server-id=1
log-bin=mysql-bin
binlog_format=mixed

爲從服務分配帳號

查看主服務器 BIN 日誌的信息

show master status;

重啓主數據庫

systemctl restart mariadb

二、配置從數據庫

鏈接主數據庫

CHANGE MASTER TO 
    -> MASTER_HOST="192.168.10.100",
    -> MASTER_USER="slave",
    -> MASTER_PASSWORD="123456",
    -> MASTER_LOG_FILE="mysql-bin.000001",
    -> MASTER_LOG_POS=388;

啓動從數據庫

start slave;