明明有個索引「感受」應該被選中，EXPLAIN時在possible_keys也有它，但最後沒被選中，可能的緣由有哪些？

目錄

• MySQL 8.0相對於5.7的複製改進，都有哪些呢？
• 跑truncate table，4億條數據會不會形成長時間鎖表呢?有什麼更好的方法嗎?
• 明明有個索引「感受」應該被選中，EXPLAIN時在possible_keys也有它，但最後沒被選中，可能的緣由有哪些？
• 主從複製線程均正常（爲Yes，也沒報錯），Master的binlog已到binlog.000100，但slave上看到Master_Log_File卻只到binlog.000090，可能的緣由有哪些?

---

1、MySQL 8.0相對於5.7的複製改進，都有哪些呢？

宋利兵老師：《MySQL 8.0相對於5.7的複製改進》的公開課也討論了這個命題，簡單歸納主要有兩部分：

（一）普通複製功能改進

一、新增WRITESET並行複製模式，提升並行度，下降延遲

二、在多源複製中，可在線動態修改每一個channel的filter rule，而且能在P_S中查看/監控

三、Binary Log中存儲更多元數據，並支持毫秒級別的延遲監控

四、對JSON Documents的複製效率更高了

五、支持DDL Crashsafe

六、增長caching_sha2_password安全策略，提升複製安全性

（二）MGR功能改進:

1.支持設置節點權重，且權重最大的在線節點將被選舉爲主

2.每一個節點中存儲更多的狀態信息，如版本、角色等

3.可根據從節點的事務狀態，自動化流控

4.離開集羣的服務器自動被設置爲read only，避免被誤操做更新數據

5.可監控MGR的內存使用狀況

2、跑truncate table，4億條數據會不會形成長時間鎖表呢?有什麼更好的方法嗎?

最好是create新表，而後交叉rename對調，再drop/truncate table或其餘方式清除數據。

（一）可操做步驟：

一、建立新的 tmp 表，正式表與tmp表表名交換（注意在一個SQL裏完成，並鎖表）

二、對 tmp 表建立硬連接 ln tmp.ibd tmp.ibd.hdlk

三、mysql中刪除表tmp（truncate / drop 都行）

四、而後找個業務不繁忙的時間刪除數據文件或者用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

3、明明有個索引「感受」應該被選中，EXPLAIN時在possible_keys也有它，但最後沒被選中，可能的緣由有哪些？
（一）執行計劃以下：

desc select * from t1 where c2 >= 2; 
key: NULL 
key_len: NULL 
rows: 14 
filtered: 92.86 
Extra: Using where

(二)可能的緣由以下：

一、隱式轉換

二、表碎片，由於表的碎片率太高

三、根據索引讀取到的數據在整個表中的數據佔比超過30%

四、統計信息沒有及時更新

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

預計掃描的行數爲14行，filtered（是指返回結果的行佔須要讀到的行的百分比）的值爲92%。

當前執行計劃中filtered值92% 說明根據索引查詢獲取的結果佔整張表的92%，在MySQL中根據索引查詢的結果佔整張表的數據30%則不會走索，因此不會走索引。
另外，也有多是表的碎片率太高或隱式轉換致使的。

4、主從複製線程均正常（爲Yes，也沒報錯），Master的binlog已到binlog.000100，但slave上看到Master_Log_File卻只到binlog.000090，可能的緣由有哪些?

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

（一）可能的緣由以下：

一、因爲sync_relay_log值太低，致使Slave頻繁刷新relay_log文件，使 Slave的硬盤資源消耗太高，因此致使SlaveIO Thread很慢。

二、Master/Slave壓力過大致使Slave IO Thread不能及時響應， 沒法及時得到Master的event。

三、網絡丟包嚴重。小包能夠鏈接而且保持鏈接不斷，可是大包就沒法發送。多是Master和Slave關於TCP MTU值設置不一致致使。

四、Master和Slave網絡連接已經斷開。但slave_net_timeout值等於0（表示徹底禁用心跳）或者slave_net_timeout和Slave_heartbeat_period很是大（表示檢測主從心跳的時間）。

五、Master的binlog很是大，io線程的file很長時間都在讀同一個。

(二)總結

本次案例是在主庫進行壓力測試，在壓力測試的過程當中，由於Master自己的壓力就很大Master來不及把binlog發送給Slave。因此表面上看起來沒有延遲，但實際上已經產生了延遲。

---

公衆號：知數堂，更多MySQL乾貨知識，關注公衆號獲取。

原文連接：https://zhishutang.com/dp8

推薦閱讀：https://zhishutang.com/xdI