《葉問》第3期

2018年6月24日，周日

MySQL 8.0相對于5.7的複制改進，都有哪些呢？

宋利兵老師：《MySQL 8.0相對于5.7的複制改進》的公開課也讨論了這個命題，簡單概括主要有兩部分：

一、普通複制功能改進 

1. 新增WRITESET并行複制模式，提高并行度，降低延遲
2. 在多源複制中，可線上動态修改每個channel的filter rule，并且能在P_S中檢視/監控
3. Binary Log中存儲更多中繼資料，并支援毫秒級别的延遲監控
4. 對JSON Documents的複制效率更高了
5. 支援DDL Crashsafe
6. 增加caching_sha2_password安全政策，提高複制安全性

二、MGR功能改進:

1. 支援設定節點權重，且權重最大的線上節點将被選舉為主
2. 每個節點中存儲更多的狀态資訊，如版本、角色等
3. 可根據從節點的事務狀态，自動化流控
4. 離開叢集的伺服器自動被設定為read only，避免被誤操作更新資料
5. 可監控MGR的記憶體使用情況

2018年6月25日，周一

跑truncate table，4億條資料會不會造成長時間鎖表呢?有什麼更好的方法嗎?

最好是create新表，然後交叉rename對調，再drop/truncate table或其他方式清除資料。 

一、可操作步驟： 

1. 建立新的 tmp 表，正式表與tmp表表名交換（注意在一個SQL裡完成，并鎖表）
2. 對 tmp 表建立硬連結 ln tmp.ibd tmp.ibd.hdlk
3. mysql中删除表tmp（truncate / drop 都行）
4. 然後找個業務不繁忙的時間删除資料檔案或者用coreutils 的truncate慢慢搞

二、關于truncate table，官檔解釋：

Logically, TRUNCATE TABLE is similar to a DELETE statement that deletes all rows, or a sequence of DROP TABLE and CREATE TABLE statements 

When a table is truncated, it is dropped and re-created in a new .ibd file, and the freed space is returned to the operating system

2018年6月26日，周二

明明有個索引“感覺”應該被選中，EXPLAIN時在possible_keys也有它，但最後沒被選中，可能的原因有哪些？ 

一、執行計劃如下：

desc select * from t1 where c2 >= 2; 

key: NULL 

key_len: NULL 

rows: 14 

filtered: 92.86 

Extra: Using where

二、可能的原因如下： 

1. 隐式轉換
2. 表碎片，因為表的碎片率過高
3. 根據索引讀取到的資料在整個表中的資料占比超過30%
4. 統計資訊沒有及時更新

三、上述執行計劃的結果是：

預計掃描的行數為14行，filtered（是指傳回結果的行占需要讀到的行的百分比）的值為92%。

目前執行計劃中filtered值92% 說明根據索引查詢擷取的結果占整張表的92%，在MySQL中根據索引查詢的結果占整張表的資料30%則不會走索，是以不會走索引。 

另外，也有可能是表的碎片率過高或隐式轉換導緻的。

2018年6月27日，周三

主從複制線程均正常（為Yes，也沒報錯），Master的binlog已到binlog.000100，但slave上看到Master_Log_File卻隻到binlog.000090，可能的原因有哪些?

首先要注意，這是Master_Log_File IO線程延遲，并不是Relay_Master_Log_File SQL線程延遲。

1. 由于sync_relay_log值過低，導緻Slave頻繁重新整理relay_log檔案，使 Slave的硬碟資源消耗過高，是以導緻SlaveIO Thread很慢。
2. Master/Slave壓力過大導緻Slave IO Thread不能及時響應， 無法及時獲得Master的event。
3. 網絡丢包嚴重。小包可以連接配接并且保持連接配接不斷，但是大包就無法發送。可能是Master和Slave關于TCP MTU值設定不一緻導緻。
4. Master和Slave網絡連結已經斷開。但slave_net_timeout值等于0（表示完全禁用心跳）或者slave_net_timeout和Slave_heartbeat_period非常大（表示檢測主從心跳的時間）。
5. Master的binlog非常大，io線程的file很長時間都在讀同一個。