溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

怎樣在磁盤上查找MySQL表的大小?這里有答案

發(fā)布時(shí)間:2020-08-10 22:33:05 來源:ITPUB博客 閱讀:198 作者:安全劍客 欄目:MySQL數(shù)據(jù)庫
我想知道 MySQL 表在磁盤上占用多少空間,但看起來很瑣碎。不應(yīng)該在 INFORMATION_SCHEMA.TABLES 中提供這些信息嗎?沒那么簡(jiǎn)單!

我想知道 MySQL 表在磁盤上占用多少空間,但看起來很瑣碎。不應(yīng)該在 INFORMATION_SCHEMA.TABLES 中提供這些信息嗎?沒那么簡(jiǎn)單!

怎樣在磁盤上查找MySQL表的大???這里有答案

這個(gè)看似簡(jiǎn)單的問題實(shí)際上在 MySQL 中非常復(fù)雜。MySQL 支持許多存儲(chǔ)引擎(其中一些根本不在磁盤上存儲(chǔ)數(shù)據(jù)), 不同的存儲(chǔ)數(shù)據(jù)格式。例如,InnoDB 存儲(chǔ)引擎為 MySQL 5.7 提供了三種“基本”格式,其中包含 row_formats 和兩種可壓縮的種類。

簡(jiǎn)化一下:我們?nèi)绾卧诖疟P上查找存儲(chǔ)在其自己的表空間中的 InnoDB 表的表大小(前提是 innodb_file_per_table=1 )。

在我們得到答案之前,先展示通過 sysbench 運(yùn)行預(yù)先獲得的圖表(批量數(shù)據(jù)插入表):

在磁盤上查找 MySQL 表的大小

怎樣在磁盤上查找MySQL表的大???這里有答案
此圖顯示了從 INFORMATION_SCHEMA.TABLES 獲取的 data_length 和 index_length 所定義的表大小。可以預(yù)期,隨著數(shù)據(jù)的增多,表格會(huì)跳躍增長(zhǎng)(有時(shí)會(huì)增加 10GB 或更多)。

該圖表與磁盤上數(shù)據(jù)的變化方式不匹配,它逐漸增長(zhǎng)(如預(yù)期):

-rw-r----- 1 mysql mysql 220293234688 Jan 25 17:03 sbtest1.ibd
-rw-r----- 1 mysql mysql 220310011904 Jan 25 17:03 sbtest1.ibd
-rw-r----- 1 mysql mysql 222499438592 Jan 25 17:07 sbtest1.ibd

正如我們從這個(gè)實(shí)驗(yàn)中看到的那樣,MySQL 并沒有真正的實(shí)時(shí)維護(hù) data_length 和 index_length 的值,而是定期刷新它們 - 而且不規(guī)則地刷新它們。圖表的后半部分一些數(shù)據(jù)刷新變得更加規(guī)律。這與圖表的第一部分不同,后者似乎每次有 10% 的行更改時(shí),就更新一次統(tǒng)計(jì)信息。table_rows, data_free 或 update_time ,它們也是實(shí)時(shí)更新的。

要在 MySQL 5.7獲取 information_schema 獲取到更準(zhǔn)確的實(shí)時(shí)信息,需要做兩件事:

禁用 innodb_stats_persistent
啟用 innodb_stats_on_metadata
這兩者都會(huì)帶來嚴(yán)重的代價(jià)。

禁用持久性統(tǒng)計(jì)信息意味著每次服務(wù)器啟動(dòng)時(shí) InnoDB 都必須刷新統(tǒng)計(jì)信息,這代價(jià)很大,并且可能會(huì)在重新啟動(dòng)之間產(chǎn)生不穩(wěn)定的查詢計(jì)劃。那有沒有更好的辦法呢?事實(shí)證明有。

可以通過 INNODB_SYS_TABLESPACES 查看表空間信息表以查看實(shí)際文件大小。與 index_length 和 data_length 不同, INNODB_SYS_TABLESPACES 實(shí)時(shí)更新,無需特殊配置:

mysql> select * from INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES where name='sbinnodb/sbtest1' \G
*************************** 1. row ***************************
SPACE: 42
NAME: sbinnodb/sbtest1
FLAG: 33
FILE_FORMAT: Barracuda
ROW_FORMAT: Dynamic
PAGE_SIZE: 16384
ZIP_PAGE_SIZE: 0
SPACE_TYPE: Single
FS_BLOCK_SIZE: 4096
FILE_SIZE: 245937209344
ALLOCATED_SIZE: 245937266688
1 row in set (0.00 sec)

使用這個(gè)表的好處是,它還處理新功能 “InnoDB 頁壓縮”,正確顯示了 file_size (磁盤上的邏輯文件大小)和 allocated_size(為此文件分配的空間,并且可以顯著縮小)之間的區(qū)別。

最后,讓我們看一下不同的 InnoDB 壓縮方式如何影響 information_schema 中提供的信息。

mysql> select * from INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES where name='sbinnodb/testcomp' G
*************************** 1. row ***************************
SPACE: 48
NAME: sbinnodb/testcomp
FLAG: 33
FILE_FORMAT: Barracuda
ROW_FORMAT: Dynamic
PAGE_SIZE: 16384
ZIP_PAGE_SIZE: 0
SPACE_TYPE: Single
FS_BLOCK_SIZE: 4096
FILE_SIZE: 285212672
ALLOCATED_SIZE: 113004544
1 row in set (0.00 sec)

如果您使用舊的 InnoDB 壓縮(InnoDB 表壓縮),您將看到 data_length 和 index_length 中顯示的壓縮數(shù)據(jù)大小作為結(jié)果。例如, avg_row_length 將遠(yuǎn)低于您的預(yù)期。

如果在 MySQL 5.7 中使用新的 InnoDB 壓縮(InnoDB 頁壓縮),您將看到與文件大小相對(duì)應(yīng)的值,而不是如 information_schema 中所示的分配大小。

結(jié)論

回答一個(gè)微不足道的問題“這個(gè)表在磁盤上占用了多少空間?” 在 MySQL 中真的不是一個(gè)簡(jiǎn)單的問題 - 顯而易見的數(shù)據(jù),可能會(huì)得到錯(cuò)誤的答案。

查看 INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES 以獲取 InnoDB 表的實(shí)際文件大小值。

原文鏈接: https://www.linuxprobe.com/find-mysql-tables.html

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI