從資料庫碎片
MySQL 8.0.16 已經發布，它像往常一樣增強了組復制 Group Replication 功能。
這篇文章介紹了 MySQL 8.0.16 為 Group Replication 帶來的新功能：
Message fragmentation（信息碎片化）。
背景
Group Replication 目前使用 XCom（一種組通信引擎），特點：原子性，組員狀態檢測等。每個成員的組復制插件先將信息轉發到本地 XCom，再由 XCom 最終以相同的順序將信息傳遞給每個組成員的 Group Replication 插件。
XCom 由單線程實現。當一些成員廣播信息過大時，XCom 線程必須花費更多的時間來處理那個大信息。如果成員的 XCom 線程忙於處理大信息的時間過長，它可能會去查看其他成員的 XCom 實例。例如，忙碌的成員失效。如果是這樣，該組可以從該組中驅逐忙碌的成員。
MySQL 8.0.13 新增group_replication_member_expel_timeout系統變數，您可以通過它來調整將成員從組中驅逐的時間。例如，懷疑成員失敗，但成員實際上忙於處理大信息，給成員足夠的時間來完成處理。在這種情況下，是否為成員增加驅逐超時的設置是一種權衡。有可能等了很久，該成員實際真的失效了。
Message fragmentation（信息碎片化）
MySQL 8.0.16 的 Group Replication 插件新增用來處理大信息的功能：信息碎片化。
簡而言之，您可以為成員的廣播信息指定最大值。超過最大值的信息將分段為較小的塊傳播。
您可以使用 group_replication_communication_max_message_size系統變數指定允許的信息最大值（默認值為10 MiB）。
示例
讓我們用一個例子來解釋新功能。圖1顯示了當綠色成員向組廣播信息時，新功能是如何處理的。
圖1 對傳出信息進行分段
1. 如果信息大小超過用戶允許的最大值（group_replication_communication_max_message_size），則該成員會將信息分段為不超過最大值的塊。
2. 該成員將每個塊廣播到該組，即將每個塊單獨轉發到XCom。
XCom 最終將這些塊提供給組成員。下面三張圖展示出了中間綠色成員發送大信息時工作的新特徵。
圖2a 重新組合傳入的信息：第一個片段
3. 成員得出結論，傳入的信息實際上是一個更大信息的片段。
4. 成員緩沖傳入的片段，因為他們認為片段是仍然不完整的信息的一部分。（片段包含必要的元數據以達到這個結論。）
圖2b 重新組合傳入的信息：第二個片段
5. 見上面的第3步。
6. 見上面的第4步。
圖2c 重新組合傳入的信息：最後一個片段
7. 成員得出結論，傳入的信息實際上是一個更大信息的片段。
8. 成員得出結論，傳入的片段是最後一個缺失的塊，重新組合原始信息，然後對其進行處理，傳輸完畢。
結論
MySQL 8.0.16 已經發布後，組復制現在可以確保組內交換的信息大小不超過用戶定義的閾值。這可以防止組內誤判而驅逐成員。
Ⅱ 什麼是內部碎片什麼是外部碎片各種存儲管理中都可能產生何種碎片
1.內部碎片：
當一個進程裝入到固定大小的分區塊（比如頁）時，假如進程所需空間小於分區塊，則分區塊的剩餘的空間將無法被系統使用，稱為內部碎片。
2.外部碎片：
指的是還沒有被分配出去（不屬於任何進程），但由於太小了無法分配給申請內存空間的新進程的內存空閑區域。
3.存儲管理中都可能產生的碎片：
除了內部碎片和外部碎片，在「分頁存儲」中，可能產生「頁內碎片」，頁內碎片是由於進程的最後一頁經常裝不滿一塊而形成了不可利用的碎片。
(2)從資料庫碎片擴展閱讀
在數據存儲領域中，碎片(fragmentation）是指存儲空間使用效率低下，結果導致功能、運行效率變低或二者兼而有之的現象。碎片化所造成的影響取決於具體的存儲系統以及碎片化的種類。
大部分情況下，碎片化都會導致都會導致存儲空間的浪費，此時「碎片」一詞亦可指代閑置的空間本身。對於其他的一些系統來說（比如FAT文件系統），數據量一定的前提下，用於存儲數據所佔的存儲空間是一定的，和碎片化的程度無關。
Ⅲ 如何檢查sql資料庫索引填充因子是否產生碎片以及如何處理
這是收藏的一些資料：
SQLServer提供了一個資料庫命令――DBCC SHOWCONTIG――來確定一個指定的表或索引是否有碎片。
示例：
顯示資料庫里所有索引的碎片信息
DBCC SHOWCONTIG WITH ALL_INDEXES
顯示指定表的所有索引的碎片信息
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
顯示指定索引的碎片信息
DBCC SHOWCONTIG (authors,aunmind)
DBCC 執行結果：
掃描頁數：如果你知道行的近似尺寸和表或索引里的行數，那麼你可以估計出索引里的頁數。看看掃描頁數，如果明顯比你估計的頁數要高，說明存在內部碎片。
掃描擴展盤區數：用掃描頁數除以8,四捨五入到下一個最高值。該值應該和DBCC SHOWCONTIG返回的掃描擴展盤區數一致。如果DBCC SHOWCONTIG返回的數高，說明存在外部碎片。碎片的嚴重程度依賴於剛才顯示的值比估計值高多少。
擴展盤區開關數：該數應該等於掃描擴展盤區數減1。高了則說明有外部碎片。
每個擴展盤區上的平均頁數：該數是掃描頁數除以掃描擴展盤區數，一般是8。小於8說明有外部碎片。
掃描密度［最佳值:實際值］：DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該盡可能靠近100％。低了則說明有外部碎片。
邏輯掃描碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。
擴展盤區掃描碎片：無序擴展盤區在掃描索引葉級頁中所佔的百分比。該百分比應該是0％，高了則說明有外部碎片。
每頁上的平均可用位元組數：所掃描的頁上的平均可用位元組數。越高說明有內部碎片，不過在你用這個數字決定是否有內部碎片之前，應該考慮fill factor（填充因子）。
平均頁密度（完整）：每頁上的平均可用位元組數的百分比的相反數。低的百分比說明有內部碎片。
解決碎片問題 ：
1. 刪除並重建索引
2. 使用DROP_EXISTING子句重建索引
3. 執行DBCC DBREINDEX
4. 執行DBCC INDEXDEFRAG
刪除並重建索引 ：
用DROP INDEX和CREATE INDEX或ALTER TABLE來刪除並重建索引有些缺陷包括在刪除重建期間索引會消失。在索引刪除重建時，對於查詢它不在可用，查詢性能也許會受到明顯的影響，直到重建索引為止。另一個潛在的缺陷是當都請求索引的時候會引起阻塞，直到重建索引為止。通過其他的處理也能解決阻塞，就是索引被使用的時候不刪除索引。另一個主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引時會引起非聚集索引重建兩次。刪除聚集索引時非聚集索引的行指針會指向數據堆，聚集索引重建時非聚集索引的行指針又會指回聚集索引的行位置。
刪除並重建索引的確有一個好處就是通過重新排序索引頁，使索引頁緊湊並刪除不需要的索引頁來完全重建索引。你也許需要考慮那些內部和外部碎片都很高的情況下才使用，以使那些索引回到它們應該在的位置。
使用DROP_EXISTING子句重建索引 ：
為了避免在重建聚集索引時表上的非聚集索引重建兩次，可以使用帶DROP_EXISTING子句的CREATE INDEX語句。這個子句會保留聚集索引鍵值，以避免非聚集索引重建兩次。和刪除並重建索引一樣，該方法也可能會引起阻塞和索引消失的問題。該方法的另一個缺陷是也強迫你去分別發現和修復表上的每一個索引。
除了和上一個方法一樣的好處之外，該方法的好處是不必重建非聚集索引兩次。這樣可以對那些帶約束的索引提供正確的索引定義以符合約束的要求。
執行DBCC DBREINDEX ：
DBCC DBREINDEX類似於第二種方法，但它物理地重建索引，允許SQLServer給索引分配新頁來減少內部和外部碎片。DBCC DBREINDEX也能動態的重建帶約束的索引，不象第二種方法。
DBCC DBREINDEX的缺陷是會遇到或引起阻塞問題。DBCC DBREINDEX是作為一個事務來運行的，所以如果在完成之前中斷了，那麼你會丟失所有已經執行過的碎片。
執行DBCC INDEXDEFRAG ：
DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引鍵的邏輯順序，通過重新整理索引里存在的葉頁來減少外部碎片，通過壓縮索引頁里的行然後刪除那些由此產生的不需要的頁來減少內部碎片。它不會遇到阻塞問題但它的結果沒有其他幾個方法徹底。這是因為DBCC INDEXDEFRAG跳過了鎖定的頁且不使用任何新頁來重新排序索引。如果索引的碎片數量大的話你也許會發現DBCC INDEXDEFRAG比重建索引花費的時間更長。DBCC INDEXDEFRAG比其他方法的確有好處的是在其他過程訪問索引時也能進行碎片整理，不會引起其他方法的阻塞問題。
Ⅳ 逐步講解 Oracle資料庫碎片如何整理
對於系統管理員來講，如何保證網路穩定運行，如何提高資料庫性能，使其更加安全高效，就顯得尤為重要。作為影響資料庫性能的一大因素 -- 資料庫碎片，應當引起 DBA 的足夠重視，及時發現並整理碎片乃是 DBA 一項基本維護內容。 1、碎片是如何產生的 當生成一個資料庫時，它會分成稱為表空間（ Tablespace ）的多個邏輯段（ Segment ），如系統（System）表空間 , 臨時（Temporary）表空間等。一個表空間可以包含多個數據范圍（Extent）和一個或多個自由范圍塊，即自由空間（Free Space）。 表空間、段、范圍、自由空間的邏輯關系如下： 當表空間中生成一個段時，將從表空間有效自由空間中為這個段的初始范圍分配空間。在這些初始范圍充滿數據時，段會請求增加另一個范圍。這樣的擴展過程會一直繼續下去，直到達到最大的范圍值，或者在表空間中已經沒有自由空間用於下一個范圍。最理想的狀態就是一個段的數據可被存在單一的一個范圍中。這樣，所有的數據存儲時靠近段內其它數據，並且尋找數據可少用一些指針。但是一個段包含多個范圍的情況是大量存在的，沒有任何措施可以保證這些范圍是相鄰存儲的，當要滿足一個空間要求時，資料庫不再合並相鄰的自由范圍（除非別無選擇）， 而是尋找表空間中最大的自由范圍來使用。這樣將逐漸形成越來越多的離散的、分隔的、較小的自由空間，即碎片。例如： 2、碎片對系統的影響 隨著時間推移，基於資料庫的應用系統的廣泛使用，產生的碎片會越來越多，將對資料庫有以下兩點主要影響： 1）導致系統性能減弱。 如上所述，當要滿足一個空間要求時，資料庫將首先查找當前最大的自由范圍，而 「最大」自由范圍逐漸變小，要找到一個足夠大的自由范圍已變得越來越困難，從而導致表空間中的速度障礙，使資料庫的空間分配愈發遠離理想狀態； 2）浪費大量的表空間。 盡管有一部分自由范圍（如表空間的 pctincrease 為非 0 ）將會被 SMON （系統監控）後台進程周期性地合並，但始終有一部分自由范圍無法得以自動合並，浪費了大量的表空間。 3、自由范圍的碎片計算 由於自由空間碎片是由幾部分組成，如范圍數量、最大范圍尺寸等，我們可用 FSFI--Free Space Fragmentation Index （自由空間碎片索引）值來直觀體現： FSFI=100*SQRT(max(extent)/sum(extents))*1/SQRT(SQRT(count(extents))) 可以看出， FSFI 的最大可能值為 100 （一個理想的單文件表空間）。隨著范圍的增加， FSFI 值緩慢下降，而隨著最大范圍尺寸的減少， FSFI 值會迅速下降。 下面的腳本可以用來計算 FSFI 值： rem FSFI Value Compute rem fsfi.sql column FSFI format 999,99 select tablespace_name,sqrt(max(blocks)/sum(blocks))* (100/sqrt(sqrt(count(blocks)))) FSFI from dba_free_space group by tablespace_name order by 1; spool fsfi.rep; / spool off;比如，在某資料庫運行腳本 fsfi.sql, 得到以下 FSFI 值： TABLESPACE_NAME FSFI ------------------------------------- RBS 74.06 SYSTEM 100.00 TEMP 22.82 TOOLS 75.79 USERS 100.00 USER_TOOLS 100.00 YDCX_DATA 47.34 YDCX_IDX 57.19 YDJF_DATA 33.80 YDJF_IDX 75.55統計出了資料庫的 FSFI 值，就可以把它作為一個可比參數。在一個有著足夠有效自由空間，且FSFI 值超過 30 的表空間中，很少會遇見有效自由空間的問題。當一個空間將要接近可比參數時，就需要做碎片整理了。 4、自由范圍的碎片整理1）表空間的 pctincrease 值為非 0。 可以將表空間的預設存儲參數 pctincrease 改為非 0 。一般將其設為 1 ，如： alter tablespace temp default storage(pctincrease 1);這樣SMON 便會將自由范圍自動合並。也可以手工合並自由范圍： alter tablespace temp coalesce。 5、段的碎片整理我們知道，段由范圍組成。在有些情況下，有必要對段的碎片進行整理。要查看段的有關信息，可查看數據字典 dba_segments ，范圍的信息可查看數據字典 dba_extents 。如果段的碎片過多， 將其數據壓縮到一個范圍的最簡單方法便是用正確的存儲參數將這個段重建，然後將舊表中的數據插入到新表，同時刪除舊表。這個過程可以用 Import/Export （輸入 / 輸出）工具來完成。 Export （）命令有一個（壓縮）標志，這個標志在讀表時會引發 Export 確定該表所分配的物理空間量，它會向輸出轉儲文件寫入一個新的初始化存儲參數 -- 等於全部所分配空間。若這個表關閉， 則使用 Import （）工具重新生成。這樣，它的數據會放入一個新的、較大的初始段中。例如： exp user/password file=exp.dmp compress=Y grants=Y indexes=Y tables=(table1,table2);若輸出成功，則從庫中刪除已輸出的表，然後從輸出轉儲文件中輸入表： imp user/password file=exp.dmp commit=Y buffer=64000 full=Y 這種方法可用於整個資料庫。 以上簡單分析了 Oracle 資料庫碎片的產生、計算方法及整理，僅供參考。資料庫的性能優化是一項技術含量高，同時又需要有足夠耐心、認真細致的工作。 對資料庫碎片的一點探討， 下面是一種如何自動處理表空間碎片的代碼，希望對上大家看上文有用 Coalesce Tablespace Automatically This technique comes from Sandeep Naik, a database administrator for GSXXI, Inc. in New York City, New York Here is a handy script which can be scheled to automatically run and coalesces the tablespaces. This script is designed to run in NT but can be run in any operating system by slight modifications in the path where the file spools from the SQLPLUS environment. It assumes that the user who runs the script has priviledges to view the data dictionary. Start of code -------------------------------------- sqlplus / prompt this script will coalesce the tablespace automatically set verify off; set termout off; set head off; spool c: empcoalesce.log select alter tablespace ||TABLESPACE_NAME|| coalesce ; from DBA_FREE_SPACE_COALESCED where PERCENT_EXTENTS_COALESCED
Ⅳ 為什麼sql server資料庫索引碎片整理
本文需要你對索引和SQL中數據的存儲方式有一定了解
在SQL Server中，存儲數據的最小單位是頁，每一頁所能容納的數據為8060位元組.而頁的組織方式是通過B樹結構（表上沒有聚集索引則為堆結構，不在本文討論之列)如下圖:
在聚集索引B樹中，只有葉子節點實際存儲數據，而其他根節點和中間節點僅僅用於存放查找葉子節點的數據.
每一個葉子節點為一頁，每頁是不可分割的. 而SQL Server向每個頁內存儲數據的最小單位是表的行(Row).當葉子節點中新插入的行或更新的行使得葉子節點無法容納當前更新或者插入的行時，分頁就產生了.在分頁的過程中，就會產生碎片.
理解外部碎片
首先，理解外部碎片的這個「外」是相對頁面來說的。外部碎片指的是由於分頁而產生的碎片.比如，我想在現有的聚集索引中插入一行，這行正好導致現有的頁空間無法滿足容納新的行。從而導致了分頁:
因為在SQL SERVER中，新的頁是隨著數據的增長不斷產生的，而聚集索引要求行之間連續，所以很多情況下分頁後和原來的頁在磁碟上並不連續.
Ⅵ 資料庫存儲空間中碎片產生的原因 及如何回收碎片
以MySQL為例，碎片的存在十分影響性能
MySQL 的碎片是 MySQL 運維過程中比較常見的問題，碎片的存在十分影響資料庫的性能，本文將對 MySQL 碎片進行一次講解。
判斷方法：
MySQL 的碎片是否產生，通過查看
show table status from table_nameG;
這個命令中 Data_free 欄位，如果該欄位不為 0，則產生了數據碎片。
產生的原因：
1. 經常進行 delete 操作
經常進行 delete 操作，產生空白空間，如果進行新的插入操作，MySQL將嘗試利用這些留空的區域，但仍然無法將其徹底佔用，久而久之就產生了碎片；
演示：
創建一張表，往裡面插入數據，進行一個帶有 where 條件或者 limit 的 delete 操作，刪除前後對比一下 Data_free 的變化。
刪除前：
Data_free 不為 0，說明有碎片；
2. update 更新
update 更新可變長度的欄位(例如 varchar 類型)，將長的字元串更新成短的。之前存儲的內容長，後來存儲是短的，即使後來插入新數據，那麼有一些空白區域還是沒能有效利用的。
演示：
創建一張表，往裡面插入一條數據，進行一個 update 操作，前後對比一下 Data_free 的變化。
CREATE TABLE `t1` ( `k` varchar(3000) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
更新語句：update t1 set k='aaa';
更新前長度：223 Data_free：0
更新後長度：3 Data_free：204
Data_free 不為 0，說明有碎片；
產生影響：
1. 由於碎片空間是不連續的，導致這些空間不能充分被利用；
2. 由於碎片的存在，導致資料庫的磁碟 I/O 操作變成離散隨機讀寫，加重了磁碟 I/O 的負擔。
清理辦法：
MyISAM：optimize table 表名；（OPTIMIZE 可以整理數據文件,並重排索引）
Innodb：
- select count(*) from test.twitter_11;
1. ALTER TABLE tablename ENGINE=InnoDB；(重建表存儲引擎，重新組織數據)
2. 進行一次數據的導入導出
碎片清理的性能對比：
引用我之前一個生產庫的數據，對比一下清理前後的差異。
SQL執行速度：
修改前：1 row in set (7.37 sec)
修改後：1 row in set (1.28 sec)
結論：
通過對比，可以看到碎片清理前後，節省了很多空間，SQL執行效率更快。所以，在日常運維工作中，應對碎片進行定期清理，保證資料庫有穩定的性能。