MySQL 8.0.16 已經(jīng)發(fā)布，它像往常一樣增強了組復(fù)制 Group Replication 功能。
創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供城子河網(wǎng)站建設(shè)、城子河做網(wǎng)站、城子河網(wǎng)站設(shè)計、城子河網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、城子河企業(yè)網(wǎng)站模板建站服務(wù)，十年城子河做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
這篇文章介紹了 MySQL 8.0.16 為 Group Replication 帶來的新功能：
Message fragmentation（信息碎片化）。
背景
Group Replication 目前使用 XCom（一種組通信引擎），特點：原子性，組員狀態(tài)檢測等。每個成員的組復(fù)制插件先將信息轉(zhuǎn)發(fā)到本地 XCom，再由 XCom 最終以相同的順序?qū)⑿畔鬟f給每個組成員的 Group Replication 插件。
XCom 由單線程實現(xiàn)。當(dāng)一些成員廣播信息過大時，XCom 線程必須花費更多的時間來處理那個大信息。如果成員的 XCom 線程忙于處理大信息的時間過長，它可能會去查看其他成員的 XCom 實例。例如，忙碌的成員失效。如果是這樣，該組可以從該組中驅(qū)逐忙碌的成員。
MySQL 8.0.13 新增??group_replication_member_expel_timeout??系統(tǒng)變量，您可以通過它來調(diào)整將成員從組中驅(qū)逐的時間。例如，懷疑成員失敗，但成員實際上忙于處理大信息，給成員足夠的時間來完成處理。在這種情況下，是否為成員增加驅(qū)逐超時的設(shè)置是一種權(quán)衡。有可能等了很久，該成員實際真的失效了。
Message fragmentation（信息碎片化）
MySQL 8.0.16 的 Group Replication 插件新增用來處理大信息的功能：信息碎片化。
簡而言之，您可以為成員的廣播信息指定最大值。超過最大值的信息將分段為較小的塊傳播。
您可以使用? group_replication_communication_max_message_size??系統(tǒng)變量指定允許的信息最大值（默認值為10 MiB）。
示例
讓我們用一個例子來解釋新功能。圖1顯示了當(dāng)綠色成員向組廣播信息時，新功能是如何處理的。
圖1 對傳出信息進行分段
1. 如果信息大小超過用戶允許的最大值（group_replication_communication_max_message_size），則該成員會將信息分段為不超過最大值的塊。
2. 該成員將每個塊廣播到該組，即將每個塊單獨轉(zhuǎn)發(fā)到XCom。
XCom 最終將這些塊提供給組成員。下面三張圖展示出了中間綠色成員發(fā)送大信息時工作的新特征。
圖2a 重新組合傳入的信息：第一個片段
3. 成員得出結(jié)論，傳入的信息實際上是一個更大信息的片段。
4. 成員緩沖傳入的片段，因為他們認為片段是仍然不完整的信息的一部分。（片段包含必要的元數(shù)據(jù)以達到這個結(jié)論。）
圖2b 重新組合傳入的信息：第二個片段
5. 見上面的第3步。
6. 見上面的第4步。
圖2c 重新組合傳入的信息：最后一個片段
7. 成員得出結(jié)論，傳入的信息實際上是一個更大信息的片段。
8. 成員得出結(jié)論，傳入的片段是最后一個缺失的塊，重新組合原始信息，然后對其進行處理，傳輸完畢。
結(jié)論
MySQL 8.0.16 已經(jīng)發(fā)布后，組復(fù)制現(xiàn)在可以確保組內(nèi)交換的信息大小不超過用戶定義的閾值。這可以防止組內(nèi)誤判而驅(qū)逐成員。
我們都知道，在mysql (這里只探討innodb) 中delete數(shù)據(jù)，并非真實刪除，而是在這行數(shù)據(jù)上打了一個del的標(biāo)記，所以這行占用的空間也并不會釋放，但是空間可以被復(fù)用，所以期望用delete數(shù)據(jù)來釋放空間的同學(xué)可以醒醒了。這樣就造成了空間上的碎片，那么如果干掉這些碎片呢。
這里先說結(jié)論，alter table語句可以觸發(fā)表重建，消除碎片空間。
mysql中的數(shù)據(jù)存儲結(jié)構(gòu)大概是下面這個樣子的
而delete掉的標(biāo)記會記錄在頭信息中。
做個實驗，看看空間是否真的沒有釋放；
創(chuàng)建一張表user，并插入很多數(shù)據(jù)
查看表的文件大小
再隨便插入幾條
ok這里看到文件大小增加了16k，這是因為mysql的一頁就是16k，所以文件大小是16k、16k的增長的。
這時候我們刪除大量的數(shù)據(jù)再次查看文件大小，仍然是272k，索命，數(shù)據(jù)雖然刪除，但是空間沒有釋放。
這里我們對主鍵執(zhí)行一個alter table語句
再次查看文件大小
ok 文件大小明顯的減少，這里說明主鍵的alter語句會重建表，并且釋放碎片空間；
這時候我們再刪除大量的數(shù)據(jù)再次查看文件大小，這里我們對普通列執(zhí)行一個alter table語句
再次查看文件大小
ok 文件大小明顯的減少，這里說明普通列的alter語句會重建表，并且釋放碎片空間；
1 log 表一般都是順序插入的，沒有大量delete的情況下是沒有所謂的碎片的。
題主要 看整理 碎片的效果 ，前提條件 表有了碎片?；蛘哳}主做了其他的動作沒有表述清楚。
2 構(gòu)造一個千萬級別行記錄的表，做大量的delete，insert ，然后查看 表的data_length 和index_length大小 ，再做 alter table xxx engine=innodb 或者 optimize table xxx;
刪除數(shù)據(jù)必然會在數(shù)據(jù)文件中造成不連續(xù)的空白空間,而當(dāng)插入數(shù)據(jù)時,這些空白空間則會被利用起來.于是造成了數(shù)據(jù)的存儲位置不連續(xù),以及物理存儲順序與理論上的排序順序不同,這種是數(shù)據(jù)碎片.實際上數(shù)據(jù)碎片分為兩種,一種是單行數(shù)據(jù)碎片,另一種是多行數(shù)據(jù)碎片.前者的意思就是一行數(shù)據(jù),被分成N個片段,存儲在N個位置.后者的就是多行數(shù)據(jù)并未按照邏輯上的順序排列.當(dāng)有大量的刪除和插入操作時,必然會產(chǎn)生很多未使用的空白空間,這些空間就是多出來的額外空間.索引也是文件數(shù)據(jù),所以也會產(chǎn)生索引碎片,理由同上,大概就是順序紊亂的問題.Engine 不同,OPTIMIZE 的操作也不一樣的,MyISAM 因為索引和數(shù)據(jù)是分開的,所以 OPTIMIZE 可以整理數(shù)據(jù)文件,并重排索引。這樣不但會浪費空間，并且查詢速度也更慢。
查看碎片信息：
Index_length 代表索引的總量
Data_free 代表碎片數(shù)量
從information_schema中獲取信息：
碎片整理：
過程時間長短取決于表大小和碎片多少，
返回結(jié)果optimize status OK則整理完成；
重慶分公司
重慶分公司
