MySQL 5.6 整理表的碎片

可以看到，當(dāng)前表的碎片率超高了，50.6%。

成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供十堰鄖陽網(wǎng)站建設(shè)、十堰鄖陽做網(wǎng)站、十堰鄖陽網(wǎng)站設(shè)計(jì)、十堰鄖陽網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、十堰鄖陽企業(yè)網(wǎng)站模板建站服務(wù)，10年十堰鄖陽做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

有三種辦法整理碎片

這三種操作都是先創(chuàng)建一個(gè)臨時(shí)表復(fù)制完成后再刪除舊表，所以在執(zhí)行操作的過程中磁盤會先增大。

會鎖表

會鎖表

pt-online-schema-change - ALTER tables 無需鎖表。

整理結(jié)果很明顯，整理后碎片率0.3%。

這里有幾個(gè)參數(shù)需要介紹一下：

--dry-run

這個(gè)參數(shù)不建立觸發(fā)器，不拷貝數(shù)據(jù)，也不會替換原表。只是創(chuàng)建和更改新表。

--execute

表明你已經(jīng)閱讀了文檔，并且確認(rèn)要 alter the table。你必須配置這個(gè)參數(shù)來 alter the table。如果你不配置，那么工具將只進(jìn)行一些安全檢查然后就退出了。這幫助確保你已經(jīng)閱讀了文檔，并且了解如何使用該工具。如果你沒有閱讀這些文檔，那么不會設(shè)置該參數(shù)。

--critical-load

每次chunk操作前后，會根據(jù)show global status統(tǒng)計(jì)指定的狀態(tài)量的變化，默認(rèn)是統(tǒng)計(jì)Thread_running。目的是為了安全，防止原始表上的觸發(fā)器引起負(fù)載過高。這也是為了防止在線DDL對線上的影響。超過設(shè)置的閥值，就會終止操作，在線DDL就會中斷。提示的異常如上報(bào)錯(cuò)信息。

--max-lag

type: time; default: 1s

lag 滯后偏移

暫停數(shù)據(jù)拷貝，直到所有replicas的lag值低于該值。在每個(gè) data-copy query (each chunk)后，工具會通過Seconds_Behind_Master查詢所有replica的 replication lag 。如果任何replica lag大于該值，那么工具會sleep --check-interval 秒，然后再次檢查所有replica。如果你指定 --check-slave-lag ，那么工具會檢查那臺server，而不是所有server。如果你想控制哪個(gè)提供工具的監(jiān)控，配置DSN值 --recursion-method 。

工具會等待直到replicas停止lagging。如果任一replica停止，工具會一直處于等待狀態(tài)直到該replica啟動(dòng)。 在所有replicas運(yùn)行并且lagging不大的情況下，數(shù)據(jù)拷貝繼續(xù)。

工具在等待的時(shí)候，會打印進(jìn)程報(bào)告。如果replica停止了，會立即打印進(jìn)程報(bào)告，然后在每個(gè)進(jìn)程報(bào)告期間重復(fù)。

--check-interval

type: time; default: 1

Sleep time between checks for --max-lag .

--max-load

選項(xiàng)定義一個(gè)閥值，在每次chunk操作后，查看show global status狀態(tài)值是否高于指定的閥值。該參數(shù)接受一個(gè)mysql status狀態(tài)變量以及一個(gè)閥值，如果沒有給定閥值，則定義一個(gè)閥值為為高于當(dāng)前值的20%。注意這個(gè)參數(shù)不會像--critical-load終止操作，而只是暫停操作。當(dāng)status值低于閥值時(shí)，則繼續(xù)往下操作。是暫停還是終止操作這是--max-load和--critical-load的差別。

--charset

簡寫: -A; type: string

設(shè)置默認(rèn)字符集。如果值為 utf8，設(shè)置 Perl’s binmode on STDOUT to utf8，傳送 mysql_enable_utf8 參數(shù)到 DBD::mysql，然后在連接到MySQL后運(yùn)行 SET NAMES UTF8 。其他的值也是在STDOUT設(shè)置 binmode，然后在連到MySQL后運(yùn)行 SET NAMES 。

--check-replication-filters

檢查復(fù)制中是否設(shè)置了過濾條件，如果設(shè)置了，程序?qū)⑼顺?/p>

--nocheck-replication-filters

不檢查復(fù)制中是否設(shè)置了過濾條件

--set-vars

設(shè)置mysql的變量值

--check-slave-lag

檢查主從延遲

--no-version-check

不檢查版本，在阿里云服務(wù)器中一般加入此參數(shù)，否則會報(bào)錯(cuò)

MySQL—碎片整理

刪除數(shù)據(jù)必然會在數(shù)據(jù)文件中造成不連續(xù)的空白空間,而當(dāng)插入數(shù)據(jù)時(shí),這些空白空間則會被利用起來.于是造成了數(shù)據(jù)的存儲位置不連續(xù),以及物理存儲順序與理論上的排序順序不同,這種是數(shù)據(jù)碎片.實(shí)際上數(shù)據(jù)碎片分為兩種,一種是單行數(shù)據(jù)碎片,另一種是多行數(shù)據(jù)碎片.前者的意思就是一行數(shù)據(jù),被分成N個(gè)片段,存儲在N個(gè)位置.后者的就是多行數(shù)據(jù)并未按照邏輯上的順序排列.當(dāng)有大量的刪除和插入操作時(shí),必然會產(chǎn)生很多未使用的空白空間,這些空間就是多出來的額外空間.索引也是文件數(shù)據(jù),所以也會產(chǎn)生索引碎片,理由同上,大概就是順序紊亂的問題.Engine 不同,OPTIMIZE 的操作也不一樣的,MyISAM 因?yàn)樗饕蛿?shù)據(jù)是分開的,所以 OPTIMIZE 可以整理數(shù)據(jù)文件,并重排索引。這樣不但會浪費(fèi)空間，并且查詢速度也更慢。

查看碎片信息：

Index_length 代表索引的總量

Data_free 代表碎片數(shù)量

從information_schema中獲取信息：

碎片整理：

過程時(shí)間長短取決于表大小和碎片多少，

返回結(jié)果optimize status OK則整理完成；

Mysql中刪除數(shù)據(jù)造成的碎片如何修復(fù)

我們都知道，在mysql (這里只探討innodb) 中delete數(shù)據(jù)，并非真實(shí)刪除，而是在這行數(shù)據(jù)上打了一個(gè)del的標(biāo)記，所以這行占用的空間也并不會釋放，但是空間可以被復(fù)用，所以期望用delete數(shù)據(jù)來釋放空間的同學(xué)可以醒醒了。這樣就造成了空間上的碎片，那么如果干掉這些碎片呢。

這里先說結(jié)論，alter table語句可以觸發(fā)表重建，消除碎片空間。

mysql中的數(shù)據(jù)存儲結(jié)構(gòu)大概是下面這個(gè)樣子的

而delete掉的標(biāo)記會記錄在頭信息中。

做個(gè)實(shí)驗(yàn)，看看空間是否真的沒有釋放；

創(chuàng)建一張表user，并插入很多數(shù)據(jù)

查看表的文件大小

再隨便插入幾條

ok這里看到文件大小增加了16k，這是因?yàn)閙ysql的一頁就是16k，所以文件大小是16k、16k的增長的。

這時(shí)候我們刪除大量的數(shù)據(jù)再次查看文件大小，仍然是272k，索命，數(shù)據(jù)雖然刪除，但是空間沒有釋放。

這里我們對主鍵執(zhí)行一個(gè)alter table語句

再次查看文件大小

ok 文件大小明顯的減少，這里說明主鍵的alter語句會重建表，并且釋放碎片空間；

這時(shí)候我們再刪除大量的數(shù)據(jù)再次查看文件大小，這里我們對普通列執(zhí)行一個(gè)alter table語句

再次查看文件大小

ok 文件大小明顯的減少，這里說明普通列的alter語句會重建表，并且釋放碎片空間；

mysql如何找出碎片率最高的表

//表名 為 top$top10 = array();$sql = "SELECT * FROM top ORDER BY nums DESC LIMIT 10";$res= mysql_query($sql);while($row = mysql_fetch_assoc($res)){ $top10[] = $row;}

超詳細(xì)MySQL數(shù)據(jù)庫優(yōu)化

數(shù)據(jù)庫優(yōu)化一方面是找出系統(tǒng)的瓶頸,提高M(jìn)ySQL數(shù)據(jù)庫的整體性能,而另一方面需要合理的結(jié)構(gòu)設(shè)計(jì)和參數(shù)調(diào)整,以提高用戶的相應(yīng)速度,同時(shí)還要盡可能的節(jié)約系統(tǒng)資源,以便讓系統(tǒng)提供更大的負(fù)荷.

1. 優(yōu)化一覽圖

2. 優(yōu)化

筆者將優(yōu)化分為了兩大類,軟優(yōu)化和硬優(yōu)化,軟優(yōu)化一般是操作數(shù)據(jù)庫即可,而硬優(yōu)化則是操作服務(wù)器硬件及參數(shù)設(shè)置.

2.1 軟優(yōu)化

2.1.1 查詢語句優(yōu)化

1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執(zhí)行信息.

2.例:

顯示:

其中會顯示索引和查詢數(shù)據(jù)讀取數(shù)據(jù)條數(shù)等信息.

2.1.2 優(yōu)化子查詢

在MySQL中,盡量使用JOIN來代替子查詢.因?yàn)樽硬樵冃枰短撞樵?嵌套查詢時(shí)會建立一張臨時(shí)表,臨時(shí)表的建立和刪除都會有較大的系統(tǒng)開銷,而連接查詢不會創(chuàng)建臨時(shí)表,因此效率比嵌套子查詢高.

2.1.3 使用索引

索引是提高數(shù)據(jù)庫查詢速度最重要的方法之一,關(guān)于索引可以參高筆者M(jìn)ySQL數(shù)據(jù)庫索引一文,介紹比較詳細(xì),此處記錄使用索引的三大注意事項(xiàng):

2.1.4 分解表

對于字段較多的表,如果某些字段使用頻率較低,此時(shí)應(yīng)當(dāng),將其分離出來從而形成新的表,

2.1.5 中間表

對于將大量連接查詢的表可以創(chuàng)建中間表,從而減少在查詢時(shí)造成的連接耗時(shí).

2.1.6 增加冗余字段

類似于創(chuàng)建中間表,增加冗余也是為了減少連接查詢.

2.1.7 分析表,,檢查表,優(yōu)化表

分析表主要是分析表中關(guān)鍵字的分布,檢查表主要是檢查表中是否存在錯(cuò)誤,優(yōu)化表主要是消除刪除或更新造成的表空間浪費(fèi).

1. 分析表: 使用 ANALYZE 關(guān)鍵字,如ANALYZE TABLE user;

2. 檢查表: 使用 CHECK關(guān)鍵字,如CHECK TABLE user [option]

option 只對MyISAM有效,共五個(gè)參數(shù)值:

3. 優(yōu)化表:使用OPTIMIZE關(guān)鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日志.,優(yōu)化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執(zhí)行過程中會加上只讀鎖.

2.2 硬優(yōu)化

2.2.1 硬件三件套

1.配置多核心和頻率高的cpu,多核心可以執(zhí)行多個(gè)線程.

2.配置大內(nèi)存,提高內(nèi)存,即可提高緩存區(qū)容量,因此能減少磁盤I/O時(shí)間,從而提高響應(yīng)速度.

3.配置高速磁盤或合理分布磁盤:高速磁盤提高I/O,分布磁盤能提高并行操作的能力.

2.2.2 優(yōu)化數(shù)據(jù)庫參數(shù)

優(yōu)化數(shù)據(jù)庫參數(shù)可以提高資源利用率,從而提高M(jìn)ySQL服務(wù)器性能.MySQL服務(wù)的配置參數(shù)都在my.cnf或my.ini,下面列出性能影響較大的幾個(gè)參數(shù).

2.2.3 分庫分表

因?yàn)閿?shù)據(jù)庫壓力過大，首先一個(gè)問題就是高峰期系統(tǒng)性能可能會降低，因?yàn)閿?shù)據(jù)庫負(fù)載過高對性能會有影響。另外一個(gè)，壓力過大把你的數(shù)據(jù)庫給搞掛了怎么辦？所以此時(shí)你必須得對系統(tǒng)做分庫分表 + 讀寫分離，也就是把一個(gè)庫拆分為多個(gè)庫，部署在多個(gè)數(shù)據(jù)庫服務(wù)上，這時(shí)作為主庫承載寫入請求。然后每個(gè)主庫都掛載至少一個(gè)從庫，由從庫來承載讀請求。

2.2.4 緩存集群

如果用戶量越來越大，此時(shí)你可以不停的加機(jī)器，比如說系統(tǒng)層面不停加機(jī)器，就可以承載更高的并發(fā)請求。然后數(shù)據(jù)庫層面如果寫入并發(fā)越來越高，就擴(kuò)容加數(shù)據(jù)庫服務(wù)器，通過分庫分表是可以支持?jǐn)U容機(jī)器的，如果數(shù)據(jù)庫層面的讀并發(fā)越來越高，就擴(kuò)容加更多的從庫。但是這里有一個(gè)很大的問題：數(shù)據(jù)庫其實(shí)本身不是用來承載高并發(fā)請求的，所以通常來說，數(shù)據(jù)庫單機(jī)每秒承載的并發(fā)就在幾千的數(shù)量級，而且數(shù)據(jù)庫使用的機(jī)器都是比較高配置，比較昂貴的機(jī)器，成本很高。如果你就是簡單的不停的加機(jī)器，其實(shí)是不對的。所以在高并發(fā)架構(gòu)里通常都有緩存這個(gè)環(huán)節(jié)，緩存系統(tǒng)的設(shè)計(jì)就是為了承載高并發(fā)而生。所以單機(jī)承載的并發(fā)量都在每秒幾萬，甚至每秒數(shù)十萬，對高并發(fā)的承載能力比數(shù)據(jù)庫系統(tǒng)要高出一到兩個(gè)數(shù)量級。所以你完全可以根據(jù)系統(tǒng)的業(yè)務(wù)特性，對那種寫少讀多的請求，引入緩存集群。具體來說，就是在寫數(shù)據(jù)庫的時(shí)候同時(shí)寫一份數(shù)據(jù)到緩存集群里，然后用緩存集群來承載大部分的讀請求。這樣的話，通過緩存集群，就可以用更少的機(jī)器資源承載更高的并發(fā)。

一個(gè)完整而復(fù)雜的高并發(fā)系統(tǒng)架構(gòu)中，一定會包含：各種復(fù)雜的自研基礎(chǔ)架構(gòu)系統(tǒng)。各種精妙的架構(gòu)設(shè)計(jì).因此一篇小文頂多具有拋磚引玉的效果,但是數(shù)據(jù)庫優(yōu)化的思想差不多就這些了.

php怎么顯示mysql數(shù)據(jù)庫的碎片？

MySQL 8.0.16 已經(jīng)發(fā)布，它像往常一樣增強(qiáng)了組復(fù)制 Group Replication 功能。

這篇文章介紹了 MySQL 8.0.16 為 Group Replication 帶來的新功能：

Message fragmentation（信息碎片化）。

背景

Group Replication 目前使用 XCom（一種組通信引擎），特點(diǎn)：原子性，組員狀態(tài)檢測等。每個(gè)成員的組復(fù)制插件先將信息轉(zhuǎn)發(fā)到本地 XCom，再由 XCom 最終以相同的順序?qū)⑿畔鬟f給每個(gè)組成員的 Group Replication 插件。

XCom 由單線程實(shí)現(xiàn)。當(dāng)一些成員廣播信息過大時(shí)，XCom 線程必須花費(fèi)更多的時(shí)間來處理那個(gè)大信息。如果成員的 XCom 線程忙于處理大信息的時(shí)間過長，它可能會去查看其他成員的 XCom 實(shí)例。例如，忙碌的成員失效。如果是這樣，該組可以從該組中驅(qū)逐忙碌的成員。

MySQL 8.0.13 新增??group_replication_member_expel_timeout??系統(tǒng)變量，您可以通過它來調(diào)整將成員從組中驅(qū)逐的時(shí)間。例如，懷疑成員失敗，但成員實(shí)際上忙于處理大信息，給成員足夠的時(shí)間來完成處理。在這種情況下，是否為成員增加驅(qū)逐超時(shí)的設(shè)置是一種權(quán)衡。有可能等了很久，該成員實(shí)際真的失效了。

Message fragmentation（信息碎片化）

MySQL 8.0.16 的 Group Replication 插件新增用來處理大信息的功能：信息碎片化。

簡而言之，您可以為成員的廣播信息指定最大值。超過最大值的信息將分段為較小的塊傳播。

您可以使用? group_replication_communication_max_message_size??系統(tǒng)變量指定允許的信息最大值（默認(rèn)值為10 MiB）。

示例

讓我們用一個(gè)例子來解釋新功能。圖1顯示了當(dāng)綠色成員向組廣播信息時(shí)，新功能是如何處理的。

圖1 對傳出信息進(jìn)行分段

1. 如果信息大小超過用戶允許的最大值（group_replication_communication_max_message_size），則該成員會將信息分段為不超過最大值的塊。

2. 該成員將每個(gè)塊廣播到該組，即將每個(gè)塊單獨(dú)轉(zhuǎn)發(fā)到XCom。

XCom 最終將這些塊提供給組成員。下面三張圖展示出了中間綠色成員發(fā)送大信息時(shí)工作的新特征。

圖2a 重新組合傳入的信息：第一個(gè)片段

3. 成員得出結(jié)論，傳入的信息實(shí)際上是一個(gè)更大信息的片段。

4. 成員緩沖傳入的片段，因?yàn)樗麄冋J(rèn)為片段是仍然不完整的信息的一部分。（片段包含必要的元數(shù)據(jù)以達(dá)到這個(gè)結(jié)論。）

圖2b 重新組合傳入的信息：第二個(gè)片段

5. 見上面的第3步。

6. 見上面的第4步。

圖2c 重新組合傳入的信息：最后一個(gè)片段

7. 成員得出結(jié)論，傳入的信息實(shí)際上是一個(gè)更大信息的片段。

8. 成員得出結(jié)論，傳入的片段是最后一個(gè)缺失的塊，重新組合原始信息，然后對其進(jìn)行處理，傳輸完畢。

結(jié)論

MySQL 8.0.16 已經(jīng)發(fā)布后，組復(fù)制現(xiàn)在可以確保組內(nèi)交換的信息大小不超過用戶定義的閾值。這可以防止組內(nèi)誤判而驅(qū)逐成員。

文章題目：mysql碎片怎么獲得 mysql表碎片率
標(biāo)題路徑：http://chinadenli.net/article32/dodhosc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、搜索引擎優(yōu)化、定制開發(fā)、移動(dòng)網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)