InnoDB磁盤空間利用率的查看方法

這篇文章主要講解了“InnoDB磁盤空間利用率的查看方法”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“InnoDB磁盤空間利用率的查看方法”吧！

 
page利用率
主要是指btee里面每個page的使用被使用的空間大小。我們知道InnoDB默認一個page大小是16k。但實際使用情況不會總用滿
我們定義為所有page的總使用字節除以總字節數。
在理論分析之前，我們要先弄個工具，查一下。
 
實例統計
寫了一個簡單的工具，讀ibd文件上的每個page，算出每個page的實際使用字節，可以得到利用率。
我們找了線上一個庫來模擬。表中有1個自增主鍵和3個非聚簇索引。不影響結論地簡化為如下：
CREATE TABLE `ctu_factor_risk_99_03` (
`seq_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`a` varchar(32) DEFAULT NULL,
`b` varchar(32) DEFAULT NULL,
`c` varchar(32) DEFAULT NULL,
KEY a (a),
KEY bc (b,c),
KEY cb (c,b),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
插入數據中a,b,c均為長度為30字節的隨機字符串。
 
顯然主鍵和其他索引應該分開統計。統計結果發現，主鍵page利用率71%，其他索引利用率約52%。
 
簡單分析
上面的結果很好理解。因為按照主鍵遞增順序插入數據，因此主鍵上數據“緊湊”。 而其他三個索引，則都是隨機更新，需要不停地作索引節點分裂。
 
如何提升磁盤空間利用率
回到最開始的問題。其實我們關心的，是InnoDB為了保存相同的數據，用了多少空間。所以我們的問題變成，存儲相同的數據，如何讓占用的磁盤空間更小。
 
         有一個很直觀的結論。把這些索引刪了重建，必然會減少空間消耗。因為這個操作之后，在新的數據插入之前，這些索引也變成“緊湊的”。
 
         再建了一個與cb相同的索引，再跑，利用率居然高達98%。這個原理大家應該都知道了，只是量化一下而已。
         工具附后， 用法 ./ibd_used tb.ibd N1 N2 >/tmp/r 最后幾行為各個索引的利用率統計值
 

感謝各位的閱讀，以上就是“InnoDB磁盤空間利用率的查看方法”的內容了，經過本文的學習后，相信大家對InnoDB磁盤空間利用率的查看方法這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！