作者：戴駿賢

網(wǎng)易游戲 技術(shù)部資深數(shù)據(jù)庫(kù)系統(tǒng)工程師。

本文來(lái)源：原創(chuàng)投稿

*愛(ài)可生開(kāi)源社區(qū)出品，原創(chuàng)內(nèi)容未經(jīng)授權(quán)不得隨意使用，轉(zhuǎn)載請(qǐng)聯(lián)系小編并注明來(lái)源。

1. 問(wèn)題起源

不久前用戶反饋部門的 MySQL 數(shù)據(jù)庫(kù)發(fā)生了數(shù)據(jù)更新丟失。為了解決這個(gè)問(wèn)題，當(dāng)時(shí)對(duì)用戶使用的場(chǎng)景進(jìn)行了分析。發(fā)現(xiàn)可能是因?yàn)橛脩粼趦膳_(tái)互為主從的機(jī)器上都進(jìn)行了寫入導(dǎo)致的數(shù)據(jù)丟失。

如圖所示，是正常和異常情況下應(yīng)用寫入數(shù)據(jù)庫(kù)的示例。隨后在更加深入調(diào)查問(wèn)題的過(guò)程中，DBA 發(fā)現(xiàn)了故障引起數(shù)據(jù)丟失的原因：

如圖 1-2 所示為故障具體過(guò)程的還原。從圖中可以看出在第 3 步 DP 上的寫入操作，在恢復(fù) DA 到 DP 的同步之后，覆蓋了第 4 步 DA 上的寫入。因此導(dǎo)致了最終兩臺(tái)機(jī)器數(shù)據(jù)不一致，并且有一部分?jǐn)?shù)據(jù)更新丟失。

在這里相信讀者都會(huì)有一個(gè)疑問(wèn)， 在第 4 步之后數(shù)據(jù)變成了(id : 1 ,name : name4)，那么第 3 步操作的時(shí)候?qū)懭氲恼Z(yǔ)句是 update t20200709 set name = 'name3' where id =1 and name='name2'，在第 5 步恢復(fù)同步的時(shí)候這條語(yǔ)句在 DA 上重放應(yīng)該不會(huì)被成功執(zhí)行，畢竟 Where 條件都不匹配了。而且在 DP 產(chǎn)生的 Binlog 中，確實(shí)也記錄了 SQL 語(yǔ)句的 Where 條件，無(wú)論從哪個(gè)角度上來(lái)看第 3 步的 SQL 語(yǔ)句都不應(yīng)該被重放成功。### UPDATE `test`.`t20200709`

### WHERE

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### @2='name2' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */

### SET

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### @2='name3' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */

# at 684315240

那么這個(gè)問(wèn)題難道是 MySQL 自身的 Bug，抑或是 MySQL 在某些特殊參數(shù)或者條件下的正常表現(xiàn)？對(duì)于這個(gè)問(wèn)題，本文將可能的給出這個(gè)問(wèn)題的詳細(xì)解釋和分析。

2. Row 格式下 RelayLog 的重放

2.1 BEFOR IMAGE && AFTER IMAGE && binlog_row_image 參數(shù)

在最后解釋本文最初提出的問(wèn)題前，需要先來(lái)看下 RelayLog 是怎么被重放的。一般情況下，當(dāng)有 DML 語(yǔ)句變更數(shù)據(jù)庫(kù)中的數(shù)據(jù)的時(shí)候，Binlog 會(huì)記錄下事件描述信息、BEFORE IMAGE 和 AFTER IMAGE 等信息。在這里有一個(gè)概念 BEFORE IMAGE 和 AFTER IMAGE 需要先介紹下：BEFORE IMAGE : 前鏡像，既數(shù)據(jù)修改前的樣子。

AFTER IMAGE : 后鏡像，既數(shù)據(jù)修改后的樣子。

為了方便理解，這里貼一個(gè) Binlog 的例子。假設(shè)當(dāng)前有表 t20200709，然后表中數(shù)據(jù)如下：mysql> select * from t20200709 ;

+----+-------+

| id | name |

+----+-------+

| 1 | name4 |

+----+-------+

1 rows in set (0.00 sec)

之后執(zhí)行 SQL 語(yǔ)句 update t20200709 set name =1 where id = 1;mysql> update t20200709 set name =1 where id = 1;

Query OK, 1 row affected (0.00 sec)

Rows matched: 1 Changed: 1 Warnings: 0

然后來(lái)看下 Binlog 中的記錄：#200715 17:28:28 server id 15218 end_log_pos 400 CRC32 0xe4dedec0 Update_rows: table id 4034114356 flags: STMT_END_F

### UPDATE `test`.`t20200709`

### WHERE

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### @2='name4' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */

### SET

### @1=1 /* INT meta=0 nullable=0 is_null=0 */

### @2='1' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */

# at 400

可以見(jiàn)得，在修改之前 name 字段的值是 'name4'，在 Binlog 中用 Where 條件 @2='name4' 來(lái)指明，而修改后的 name 的值是 '1'，在 Binlog 中就是 @2='1' 來(lái)指明。因此 BEFORE IMAGE 就是 Binlog 中 WHERE 到 SET 的部分。而 AFTER IMAGE 就是 SET 之后的部分。

那么 DELETE，UPDATE 和 INSERT 語(yǔ)句被記錄在 Binlog 中的時(shí)候，是否都有 BEFORE IMAGE 和 AFTER IMAGE？其實(shí)不是所有的 DML 事件類型都擁有兩個(gè) IMAGE 的，參見(jiàn)圖 2-2 可知只有 UPDATE 語(yǔ)句，會(huì)同時(shí)擁有 BEFORE IMAGE 和 AFTER IMAGE。

BEFOR IMAGE 和 AFTER IMAGE 默認(rèn)會(huì)記錄所有的列的變更，因此會(huì)導(dǎo)致 Binlog 的內(nèi)容變得很大。那么有沒(méi)有參數(shù)可以控制 IMAGE(對(duì)于 BEFOR IMAGE 和 AFTER IMAGE 以下合并簡(jiǎn)稱為 IMAGE)的行為？MySQL5.7 之后引入了一個(gè)新的參數(shù) binlog_row_image

用于控制 IMAGE 的行為。binlog_row_image 參數(shù)的值有三個(gè)：full：Log all columns in both the before image and the after image. 既所有的列的值的變更，都會(huì)在IMAGE中記錄。系統(tǒng)默認(rèn)是full。

minimal：Log only those columns in the before image that are required to identify the row to be changed; log only those columns in the after image where a value was specified by the SQL statement, or generated by auto-increment. BEFOR IMAGE 只記錄哪些能夠唯一標(biāo)識(shí)數(shù)據(jù)的列，比如主鍵，唯一鍵等。AFTER IMAGE 只記錄了變更的列。可以看出，minimal會(huì)有效的減少Binlog的大小。

noblob：Log all columns (same as full), except for BLOB and TEXT columns that are not required to identify rows, or that have not changed. 對(duì)于其他列的行為都和 full 參數(shù)一樣。但是對(duì)于 BLOB 和 TEXT，在不是可以標(biāo)識(shí)數(shù)據(jù)行或者有變更的情況下不做記錄。

可以看出binlog_row_image可以有效控制Binlog的大小，但是如果要保證數(shù)據(jù)的一致性，最好的值就是設(shè)置為full。

2.2 slave_rows_search_algorithms 參數(shù)

前文提到了 IMAGE 與 binlog_row_image 相關(guān)的內(nèi)容。本節(jié)開(kāi)始將主要介紹 Relay Log 的重放的時(shí)候，對(duì)于被重放的記錄的查找邏輯。對(duì)于 DELETE 和 UPDATE 操作，需要先對(duì)數(shù)據(jù)庫(kù)中的記錄進(jìn)行檢索以確定需要執(zhí)行 Binlog 重放的數(shù)據(jù)。如果從庫(kù)的表上沒(méi)有主鍵或唯一鍵時(shí)，則需要根據(jù)每一個(gè)行記錄 BEFOR IMAGE 在所有數(shù)據(jù)中進(jìn)行一次全表掃描。在大多數(shù)情況下這種開(kāi)銷非常巨大，會(huì)導(dǎo)致從庫(kù)和主庫(kù)的巨大延遲。從 MySQL5.6 開(kāi)始提供了參數(shù) slave_rows_search_algorithms參數(shù)說(shuō)明：

用于控制在 Relay Log 執(zhí)行重放的時(shí)候?qū)τ谟涗浀臋z索行為。其基本的思路是收集每條記錄的 BEFOR IMAGE 信息，然后根據(jù) BEFOR IMAGE 的信息在被重放的表中檢索對(duì)應(yīng)的記錄。根據(jù) MySQL 的文檔，檢索數(shù)據(jù)的方式有如下的幾種：INDEX_SCAN

TABLE_SCAN

HASH_SCAN

如上三個(gè)方式可以兩兩組合并賦值給 slave_rows_search_algorithms 參數(shù)。MySQL 文檔也給出了如下的說(shuō)明：Index used / option valueINDEX_SCAN,HASH_SCANINDEX_SCAN,TABLE_SCANPrimary key or unique keyIndex scanIndex scan

(Other) KeyHash scan over indexIndex scan

No indexHash scanTable scanThe default value is INDEX_SCAN,TABLE_SCAN, which means that all searches that can use indexes do use them, and searches without any indexes use table scans.

To use hashing for any searches that do not use a primary or unique key, set INDEX_SCAN,HASH_SCAN. Specifying INDEX_SCAN,HASH_SCAN has the same effect as specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN, which is allowed.

Do not use the combination TABLE_SCAN,HASH_SCAN. This setting forces hashing for all searches. It has no advantage over INDEX_SCAN,HASH_SCAN, and it can lead to “record not found” errors or duplicate key errors in the case of a single event containing multiple updates to the same row, or updates that are order-dependent.INDEX_SCAN,TABLE_SCAN: 可以看出在默認(rèn)的情況下，既 INDEX_SCAN,TABLE_SCAN 如果有主鍵或者唯一鍵，則通過(guò)主鍵或者唯一鍵來(lái)查詢數(shù)據(jù)并重放 AFTER IMAGE。如果沒(méi)有主鍵或者唯一鍵，則通過(guò)二級(jí)索引完成這個(gè)工作。如果什么都沒(méi)有，則使用全表掃描的方式。

INDEX_SCAN,HASH_SCAN : 在表有主鍵或者唯一鍵的情況下， INDEX_SCAN,HASH_SCAN 配置也是使用的主鍵或者唯一鍵去定位數(shù)據(jù)。在表有二級(jí)索引或者完全沒(méi)有索引的情況下會(huì)使用 HASH_SCAN 的方法。

可以見(jiàn)得 Slave 檢索需要重放的數(shù)據(jù)的時(shí)候，三個(gè)檢索方式的優(yōu)先級(jí)是 Index Scan > Hash Scan > Table Scan

相信讀者在這里會(huì)有 2 個(gè)疑問(wèn)：Hash Scan 的原理是什么？它和 Table Scan 以及 Index Scan 有什么區(qū)別？文檔中還提到了 Hash scan over index 這個(gè)和 Index 有什么關(guān)系？

前文提到在表沒(méi)有主鍵或者唯一鍵的時(shí)候，會(huì)通過(guò)二級(jí)索引來(lái)定位數(shù)據(jù)。假設(shè)表中有 N 個(gè)二級(jí)索引(包括單列索引和聯(lián)合索引)，哪個(gè)二級(jí)索引會(huì)被選中？

2.3 Hash Scan && Table Scan && Index Scan 實(shí)現(xiàn)

分析 MySQL 源碼可知最后決定使用哪個(gè)檢索方式是在函數(shù) Rows_log_event::decide_row_lookup_algorithm_and_key 里面實(shí)現(xiàn)的。9745 void

9746 Rows_log_event::decide_row_lookup_algorithm_and_key()

9747 {

9748

... ...

9781 /* PK or UK => use LOOKUP_INDEX_SCAN */

9782 this->m_key_index= search_key_in_table(table, cols, (PRI_KEY_FLAG | UNIQUE_KEY_FLAG));

9783 if (this->m_key_index != MAX_KEY)

9784 {

9785 DBUG_PRINT("info", ("decide_row_lookup_algorithm_and_key: decided - INDEX_SCAN"));

9786 this->m_rows_lookup_algorithm= ROW_LOOKUP_INDEX_SCAN;

9787 goto end;

9788 }

... ...

9790 TABLE_OR_INDEX_HASH_SCAN:

... ...

9808 TABLE_OR_INDEX_FULL_SCAN:

... ...

9827 end:

... ...

在 9782 行會(huì)先檢索表中是否有主鍵和唯一鍵。之后在 TABLE_OR_INDEX_HASH_SCAN 和 TABLE_OR_INDEX_FULL_SCAN 決定最后使用哪種檢索方式。在 do_apply_event 函數(shù)中，會(huì)根據(jù) decide_row_lookup_algorithm_and_key 的結(jié)果去調(diào)用函數(shù):11286 switch (m_rows_lookup_algorithm)

11287 {

11288 case ROW_LOOKUP_HASH_SCAN:

11289 do_apply_row_ptr= &Rows_log_event::do_hash_scan_and_update;

11290 break;

11291

11292 case ROW_LOOKUP_INDEX_SCAN:

11293 do_apply_row_ptr= &Rows_log_event::do_index_scan_and_update;

11294 break;

11295

11296 case ROW_LOOKUP_TABLE_SCAN:

11297 do_apply_row_ptr= &Rows_log_event::do_table_scan_and_update;

11298 break;

11299

11300 case ROW_LOOKUP_NOT_NEEDED:

11301 DBUG_ASSERT(get_general_type_code() == binary_log::WRITE_ROWS_EVENT);

11302

11303 /* No need to scan for rows, just apply it */

11304 do_apply_row_ptr= &Rows_log_event::do_apply_row;

11305 break;

11306

11307 default:

11308 DBUG_ASSERT(0);

11309 error= 1;

11310 goto AFTER_MAIN_EXEC_ROW_LOOP;

11311 break;

11312 }

可以見(jiàn)得：do_hash_scan_and_update: 對(duì)應(yīng) hash_scan 方式。

do_index_scan_and_update: 對(duì)應(yīng) index_scan 方式。

do_table_scan_and_update:對(duì)應(yīng) table_scan 方式。

接下來(lái)分別介紹下這三個(gè)函數(shù)所完成的內(nèi)容。

2.3.1 do_hash_scan_and_update

do_hash_scan_and_update 函數(shù)主要實(shí)現(xiàn)了 Hash Scan 檢索數(shù)據(jù)的功能。在實(shí)現(xiàn)方式上又可以分為 H --> Hash Scan 和 Hi --> Hash over Index 兩種方式。首先來(lái)看下 Hash Scan 的實(shí)現(xiàn)方法，圖 2-5 給出 Hash Scan 的實(shí)現(xiàn)邏輯。

可以見(jiàn)得 Binlog 中的 BI 在 Slave 上會(huì)被處理到一個(gè) Hash 表中。因?yàn)闆](méi)有合適的索引可以使用，所以使用全表掃描的方式每獲取一條記錄就根據(jù)記錄的值計(jì)算一個(gè) hash 值，然后在 BI 的 Hash 表中匹配。如果匹配到了 BI，則重放并刪除 Hash 表中的記錄。

如果 test06 表中 id 列上有索引，那么在 Slave 重放的使用會(huì)使用 Hi --> Hash over index 的方式。如圖 2-6 所示給出了 Hash over Index 方式(以下均簡(jiǎn)稱 Hi)的實(shí)現(xiàn)邏輯。

可以見(jiàn)得如果通過(guò) Hi 方式進(jìn)行重放，則會(huì)對(duì)使用的二級(jí)索引生成一個(gè) m_distinct_keys 結(jié)構(gòu)，這個(gè)結(jié)構(gòu)存放著這個(gè) BI 中這個(gè)索引所有的去重值。然后對(duì)于 Slave 上的 test06 表通過(guò) m_distinct_keys 中的每一個(gè)值在二級(jí)索引上進(jìn)行遍歷，遍歷獲取的記錄與 m_hash 中的結(jié)果對(duì)比并執(zhí)行重放邏輯。

ps : 對(duì)于 Hash Scan 方式還要一個(gè)比較迷惑的特性，讀者可以參考下這篇文章技術(shù)分享 | HASH_SCAN BUG 之迷惑行為大賞

2.3.2 do_index_scan_and_update

Index Scan 方式會(huì)通過(guò)索引檢索 Slave 上需要重放的數(shù)據(jù)。通過(guò)索引檢索數(shù)據(jù)的方式又可以分為:通過(guò)主鍵/唯一鍵索引檢索數(shù)據(jù)。

通過(guò)二級(jí)索引檢索數(shù)據(jù)。

在通過(guò)主鍵或者唯一鍵索引檢索數(shù)據(jù)的時(shí)候會(huì)調(diào)用 do_index_scan_and_update 函數(shù)，在函數(shù)邏輯中直接通過(guò)主鍵/唯一鍵索引返回了記錄然后重放 Binlog。

而在通過(guò)二級(jí)索引檢索數(shù)據(jù)的時(shí)候，會(huì)對(duì)二級(jí)索引返回的數(shù)據(jù)與 BI 中每一條記錄做比較，如果一致就會(huì)重放 Binlog。

至此可以發(fā)現(xiàn) Index Scan 下對(duì)于主鍵/唯一鍵和二級(jí)索引的實(shí)現(xiàn)邏輯有一些不同。對(duì)于主鍵/唯一鍵，對(duì)于索引到的記錄并不會(huì)和 BI 中的每一個(gè)列做比較，而二級(jí)索引獲取到的數(shù)據(jù)會(huì)與 BI 中每一個(gè)列做比較，如果不一致而不會(huì)重放并報(bào)錯(cuò)。

2.3.3 do_table_scan_and_update

Table Scan 的實(shí)現(xiàn)相對(duì)簡(jiǎn)單，如果沒(méi)有任何的索引可以使用，只能通過(guò)全表掃描的方式獲取每一行數(shù)據(jù)并和BI中的每一行做比較。因此如果 Slave 上的數(shù)據(jù)和 Master 上的數(shù)據(jù)不一致，也會(huì)如圖 2-9 中所示一樣報(bào)錯(cuò)。關(guān)于 Table Scan 更加具體的實(shí)現(xiàn)方式，讀者可以參考 MySQL 源碼 sql/log_event.cc 文件中的 do_table_scan_and_update 函數(shù)，在這里就不過(guò)多的展開(kāi)。

2.3.4 小結(jié)

至此可以回答本文之前提出的這個(gè)問(wèn)題了：Hash scan 方法的原理是什么？它和 Table scan 以及 Index scan 有什么區(qū)別？文檔中還提到了 Hash scan over index 這個(gè)和 Index 又有什么關(guān)系？

可以見(jiàn)得，Hash Scan 的原理是將 BI 每一行的內(nèi)容都放入一個(gè) Hash 表中。如果可以使用二級(jí)索引(既 Hash scan over index 這個(gè)方式)，則額外的對(duì) BI 中二級(jí)索引的值生成一個(gè) Hash 結(jié)構(gòu)，并且將 BI 中二級(jí)索引列的去重值放入這個(gè) Hash 結(jié)構(gòu)中。之后不管是通過(guò)全表掃描還是索引的方式獲取數(shù)據(jù)，都會(huì)通過(guò) Hash 結(jié)構(gòu)去定位 BI 中的數(shù)據(jù)。對(duì)于 Table Scan 和 Index Scan 在獲取表中的每一行之后，都需要去和 BI 中的記錄做一次查找和比較(有主鍵或者唯一鍵的時(shí)候不做比較)，而 BI 的每一行并沒(méi)有生成類似于 Hash 的結(jié)構(gòu)，因此從算法的時(shí)間復(fù)雜度效率上來(lái)說(shuō)是屬于 O(n^2) 的。而 Hash Scan 在獲取一條記錄之后也需要根據(jù) BI 生成的 Hash 結(jié)構(gòu)中查找記錄，但是對(duì)于 Hash 結(jié)構(gòu)的查找來(lái)說(shuō)效率是 O(1)，因此可以忽略不計(jì)。由此可以看出，在沒(méi)有主鍵的情況下 Hi 和 Ht 方式的效率是會(huì)比 Table Scan 和 Index Scan 來(lái)的高一些。

同時(shí)到這里，也可以回答本文開(kāi)頭的問(wèn)題，為什么當(dāng)前表中的記錄有一列值已經(jīng)和 BI 中的記錄不一致了，Binlog 中的操作還會(huì)重放。原因就是因?yàn)樵谀J(rèn)的 INDEX_SCAN,TABLE_SCAN 方式下，對(duì)于有主鍵/唯一鍵的表不會(huì)去比較 BI 中的記錄是否和檢索到的數(shù)據(jù)一致。

2.4 Hash Scan Over Index && Index Scan 中二級(jí)索引的選擇

前文提到了在有二級(jí)索引的情況下，Hash Scan 和 Index Scan 都會(huì)選擇二級(jí)索引進(jìn)行掃描。如果表中存在多個(gè)二級(jí)索引，MySQL 會(huì)選擇哪個(gè)？通過(guò)源碼分析，最后驚訝的發(fā)現(xiàn)，在 binlog_row_image 參數(shù)是 Full 的情況下，如果表中存在多個(gè)二級(jí)索引，MySQL 會(huì)默認(rèn)選擇使用第一個(gè)索引進(jìn)行重放。在 decide_row_lookup_algorithm_and_key 函數(shù)中，除了決定了使用哪種方式檢索數(shù)據(jù)以外(例如使用 Hash Scan 還是 Table Scan)，也決定了后續(xù)使用哪個(gè)索引。

如圖 2-10 給出了選擇二級(jí)索引的時(shí)候的邏輯。可以發(fā)現(xiàn)如果在遍歷的過(guò)程中，找到了第一個(gè)所有的列都在 BI 中 key，則會(huì)使用這個(gè) key。給出一個(gè)例子，test06 的表結(jié)構(gòu)和表中數(shù)據(jù)如下:*************************** 1. row ***************************

Table: test06

Create Table: CREATE TABLE `test06` (

`id` int(11) NOT NULL,

`name` varchar(255) DEFAULT NULL,

`c1` int(11) DEFAULT NULL,

KEY `k1` (`id`),

KEY `k2` (`id`,`name`),

KEY `k3` (`c1`,`name`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8

1 row in set (0.13 sec)

mysql> select * from test06 ;

+------+-------+------+

| id | name | c1 |

+------+-------+------+

| 2582 | name3 | 1 |

| 2582 | name4 | 1 |

| 1 | name1 | 0 |

| 1 | name2 | 0 |

| 1 | name3 | 0 |

+------+-------+------+

5 rows in set (0.00 sec)

在 Master 上執(zhí)行 SQL，同時(shí) Master 上的執(zhí)行計(jì)劃如下:delete from test06 where id = 1 and name ='name3' and c1=0;

mysql> explain delete from test06 where id = 1 and name ='name3' and c1=0;

+----+-------------+--------+------------+-------+---------------+------+---------+-------------+------+----------+-------------+

| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |

+----+-------------+--------+------------+-------+---------------+------+---------+-------------+------+----------+-------------+

| 1 | DELETE | test06 | NULL | range | k1,k2,k3 | k2 | 772 | const,const | 1 | 100.00 | Using where |

+----+-------------+--------+------------+-------+---------------+------+---------+-------------+------+----------+-------------+

1 row in set (0.00 sec)

可以見(jiàn)得，在 Master 上優(yōu)化器選擇了 k2 這個(gè)聯(lián)合索引。通過(guò) GDB 跟蹤 Slave 的進(jìn)程，在 log_event.cc 第 9733 行打斷點(diǎn):9714 if (key_type & MULTIPLE_KEY_FLAG && table->s->keys)

9715 {

9716 DBUG_PRINT("debug", ("Searching for K."));

9717 for (key=0,keyinfo= table->key_info ;

9718 (key < table->s->keys) && (res == MAX_KEY);

9719 key++,keyinfo++)

9720 {

9721 /*

9722 - Skip innactive keys

9723 - Skip unique keys without nullable parts

9724 - Skip indices that do not support ha_index_next() e.g. full-text

9725 - Skip primary keys

9726 */

9727 if (!(table->s->keys_in_use.is_set(key)) ||

9728 ((keyinfo->flags & (HA_NOSAME | HA_NULL_PART_KEY)) == HA_NOSAME) ||

9729 !(table->file->index_flags(key, 0, true) & HA_READ_NEXT) ||

9730 (key == table->s->primary_key))

9731 continue;

9732

9733 res= are_all_columns_signaled_for_key(keyinfo, bi_cols) ?

9734 key : MAX_KEY;

9735

9736 if (res < MAX_KEY)

9737 DBUG_RETURN(res);

9738 }

9739 DBUG_PRINT("debug", ("Not all columns signaled for K."));

9740 }

可以觀察到這時(shí)候 m_key_index 的值是 0，并且觀察 keyinfo 變量的值為:(gdb) print *keyinfo

$4 = {key_length = 4, flags = 0, actual_flags = 0, user_defined_key_parts = 1, actual_key_parts = 1, unused_key_parts = 0, usable_key_parts = 1, block_size = 0, algorithm = HA_KEY_ALG_UNDEF, {

parser = 0x0, parser_name = 0x0}, key_part = 0x7f2f4c015a00, name = 0x7f2f4c012bb1 "k1", rec_per_key = 0x7f2f4c012bc0, m_in_memory_estimate = -1, rec_per_key_float = 0x7f2f4c012bf8, handler = {

bdb_return_if_eq = 0}, table = 0x7f2f4c92d1a0, comment = {str = 0x0, length = 0}}

接下來(lái)，刪除 k1 這個(gè)索引，再來(lái)觀察下 m_key_index 和 keyinfo 的值。(gdb) print *keyinfo

$7 = {key_length = 772, flags = 64, actual_flags = 64, user_defined_key_parts = 2, actual_key_parts = 2, unused_key_parts = 0, usable_key_parts = 2, block_size = 0, algorithm = HA_KEY_ALG_UNDEF, {

parser = 0x0, parser_name = 0x0}, key_part = 0x7f2f4c92b680, name = 0x7f2f4c92e7d1 "k2", rec_per_key = 0x7f2f4c92e7d8, m_in_memory_estimate = -1, rec_per_key_float = 0x7f2f4c92e808, handler = {

bdb_return_if_eq = 0}, table = 0x7f2f4ca9fd90, comment = {str = 0x0, length = 0}}

可以發(fā)現(xiàn)刪除了 k1 之后，Slave 上就選擇 k2 這個(gè)索引，和 Master上的執(zhí)行計(jì)劃選擇的索引一致了。通過(guò)前面的源碼分析和調(diào)試跟蹤可以發(fā)現(xiàn)，MySQL 在 Slave 重放數(shù)據(jù)的時(shí)候(沒(méi)有主鍵和唯一鍵的情況)，選擇的索引是第一個(gè)所有的列都在 BI 中存在的索引。因此可能存在 Slave 上選擇的索引不是最優(yōu)的導(dǎo)致 Slave 和 Master 有巨大延遲。

3. 總結(jié)

至此前文提出的幾個(gè)問(wèn)題都基本清楚了，可以總結(jié)出如下的幾點(diǎn)內(nèi)容：在有主鍵或者唯一鍵的情況下，Slave 重放 Binlog 并不會(huì)去比較檢索到的記錄的每一列是否和BI相同，因此如果 Slave 和 Master 存在數(shù)據(jù)不一致，會(huì)直接覆蓋 Slave 的數(shù)據(jù)而不會(huì)報(bào)錯(cuò)。

在沒(méi)有主鍵或者唯一鍵的情況下，Hash Scan / Hash Scan Over Index 的執(zhí)行效率 在理論上分析高于 Table Scan 和Index Scan 。

在沒(méi)有主鍵或者唯一鍵的情況下，Slave 選擇的二級(jí)索引是第一個(gè)所有的列都在 BI 中存在的索引，不一定是 Master 執(zhí)行計(jì)劃所選擇的索引。

最后本文所有分析的源碼都是基于 mysql-5.7.28 版本。限于作者的水平有限，如果文章中有錯(cuò)誤之處，望大家不吝指正。

4. 參考文獻(xiàn)

[1]. MySQL無(wú)主鍵延遲優(yōu)化(slave_rows_search_algorithms). https://www.centos.bz/2018/01...(slave_rows_search_algorithms)

[2]. MySQL 5.7貼心參數(shù)之binlog_row_image. https://www.cnblogs.com/gomys...

[3]. 技術(shù)分享 | delete大表slave回放巨慢的問(wèn)題分析. https://mp.weixin.qq.com/s/ae...

[4]. Causes and Workarounds for Slave Performance Too Slow with Row-Based Events. https://www.percona.com/blog/...

[5]. 技術(shù)分享 | 從庫(kù)數(shù)據(jù)的查找和參數(shù) slave_rows_search_algorithms. https://mp.weixin.qq.com/s/Jh...

[6]. 技術(shù)分享 | HASH_SCAN BUG 之迷惑行為大賞. https://mp.weixin.qq.com/s/7z...

總結(jié)

以上是生活随笔為你收集整理的mysql主从数据丢失_故障分析 | 记一次 MySQL 主从双写导致的数据丢失问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。