MySQL InnoDB表的碎片量化和整理（data free可否用来衡量碎片？）

网络上有不少MySQL表碎片整理的问题，大多数是经过demo一个表而后参考data free来进行碎片整理，这种方式对myisam引擎或者其余引擎可能有效（本人没有作详细的测试）.
对Innodb引擎是否是准确的，或者data free是否是能够参考，仍是值得商榷的。
本文基于MySQL的Innodb存储引擎，数据库版本是8.0.18，对碎片（fragment）作一个简单的分析，来讲明如何量化表的碎片化程度。

涉及的参数
1，information_schema_stats_expiry
information_schema是一个基于共享表空间的虚拟数据库，存储的是一些系统元数据信息，某些系统表的数据并非实时更新的，具体更新是基于参数information_schema_stats_expiry。
information_schema_stats_expiry默认值是86400秒，也就是24小时，意味着24小时刷新一次information_schema中的数据，作测试的时候能够设置为0，实时刷新information_schema中的元数据信息。
2，innodb_fast_shutdown
由于要基于磁盘作一些统计，须要将缓存或者redo log中的数据在重启实例的时候实时刷入磁盘，这里设置为0，在重启数据库的时候将缓存或者redo log实时写入表的物理文件。
3，innodb_stats_persistent_sample_pages
由于涉及一些系统数据更新时对page的采样比例，这里设置为一个较大的值，为100000，尽量高比例采样来生成系统数据。
4，innodb_flush_log_at_trx_commit sync_binlog 
由于涉及大量数据的写操做，为加快测试，关闭double 1模式。
5，innodb_fill_factor
页面填充率保留默认的设置，默认值是100
以上涉及的参数仅针对本测试，并不必定表明最优，同时测试过程当中（数据写入或者删除后）会不断地重启实例，以刷新相对应的物理文件。

碎片的概念
数据存储在文件系统上的时候，老是不能100%利用分配给它的物理空间，好比删除数据会在页面上留下一些”空洞”，或者随机写入（汇集索引非线性增长）会致使页分裂，页分裂会致使页面的利用空间少于50%。
另外对表进行增删改，包括对应的二级索引值的随机的增删改，都会致使数据页面上留下一些“空洞”，虽然这些位置有可能会被重复利用，但终究会致使部分物理空间未被使用，也就是碎片。
即使是设置了填充因子为100%，Innodb也会主动留下page页面1/16的空间做为预留使用（An innodb_fill_factor setting of 100 leaves 1/16 of the space in clustered index pages free for future index growth.）。
关系数据库的存储结构原理上是相似的，理论上很简单，就不过多啰嗦了。

测试表以及数据

作个简单的测试，表结构以下，

CREATE TABLE `fragment_test` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `c1` INT NULL DEFAULT NULL,
    `c2` INT NULL DEFAULT NULL,
    `c3` VARCHAR(50) NULL DEFAULT NULL,
    `c4` DATETIME(6) NULL DEFAULT NULL,
    PRIMARY KEY (`id`) 
);

CREATE INDEX idx_c1 ON fragment_test(c1);
CREATE INDEX idx_c2 ON fragment_test(c2);
CREATE INDEX idx_c3 ON fragment_test(c3);

生成200W测试数据（CALL test_insertdata(2000000);）

CREATE DEFINER=`root`@`%` PROCEDURE `test_insertdata`(
    IN `loopcount` INT
)
BEGIN
  declare v_uuid  varchar(50);
    while loopcount>0 do
        set v_uuid = uuid();
        INSERT INTO fragment_test(c1,c2,c3,c4) VALUES (RAND()*200000000,RAND()*200000000,UUID(),NOW(6));
        set loopcount = loopcount -1;
    end while;
END

查询语句，参考自最后的连接中的文章

SELECT NAME, 
        TABLE_ROWS,
        UPDATE_TIME, 
            format_bytes(data_length) DATA_SIZE,
       format_bytes(index_length) INDEX_SIZE,
       format_bytes(data_length+index_length) TOTAL_SIZE,
       format_bytes(data_free) DATA_FREE,
       format_bytes(FILE_SIZE) FILE_SIZE,
       format_bytes((FILE_SIZE/10 - (data_length/10 + 
                           index_length/10))*10) WASTED_SIZE  
FROM information_schema.TABLES as t 
JOIN information_schema.INNODB_TABLESPACES as it 
  ON it.name = concat(table_schema,"/",table_name) 
WHERE TABLE_NAME = 'fragment_test';

 

碎片的测试
上面说到数据在存储的时候，老是没法100%利用物理存储空间，Innodb甚至会本身主动预留一部分空闲的空间（1/16），那么如何衡量一个表究竟有多少还没有利用的空间？
这里从系统表information_schema.tables和information_schema.innodb_tablespaces，来对比实际使用空间和已分配空间来对比，来间接量化碎片或者说未利用空间的程度。

而后观察数据空间的分配状况，尽管系统表中的数据不是彻底准确的，可是也比较接近实际的200W，系统表显示1971490，暂时抛开这一小点偏差。
能够很清楚地看到，数据和索引的空间是329MB，文件空间是344MB，DATA_FREE空间是6MB。

随机删除1/4的数据，也就是50W行，而后重启实例，并分析表（analyze table），继续来观察这个空间的分配（DELETE FROM fragment_test ORDER BY RAND() LIMIT 500000;）
这里看到，
1，系统表显示150000行，跟表中的数据彻底一致（尽管更多的时候这个值是一个大概的值，并不必定准确，严格说可能很是不许确，这里归因于innodb_stats_persistent_sample_pages的设置）。
2，数据文件空间没有增长（344MB），能够理解，由于这里是删数据操做，因此不用申请空间。
3，删除了1/4的数据，数据和索引的的大小基本上不变，这里就开始有疑问了，为何没有成比例减小？
4，data_free增长了3MB，显然这不是跟删除的数据成比例增长的
那么怎么理解碎片？DATA_FREE怎么理解？碎片或者说可用空间又怎么衡量？

从200W数据中随机删除50W，也就是1/4，表的空间没有变化，能够确定的是如今存在大量的碎片或者说可用空间，可是表的总的大小没变化，data_free也基本上没有变化到这里就有点说不通了。
那么data free究竟是怎么计算的，看官方的解释：

The number of allocated but unused bytes.
InnoDB tables report the free space of the tablespace to which the table belongs. For a table located in the shared tablespace, this is the free space of the shared tablespace.
If you are using multiple tablespaces and the table has its own tablespace, the free space is for only that table.
Free space means the number of bytes in completely free extents minus a safety margin. Even if free space displays as 0, it may be possible to insert rows as long as new extents need not be allocated.
data_free的计算方式或者说条件，是彻底空闲的区（extents，每一个区1MB，64个连续的16 kb 大小的page），只有一个彻底没有使用的区，才统计为data_free，所以data_free并不能反映出来真正的空闲空间。

同时测试中发现，performance_schema.tables中的table_rows会受到innodb_stats_persistent_sample_pages的影响，可是data_length和index_length看起来是不会受innodb_stats_persistent_sample_pages的影响的
这里采样比例已经足够大，尽管table_rows已是一个彻底准确的数字了，可是data_length和index_length却仍旧是一个偏差很是大的数字。
说到这里，那么这个碎片问题如何衡量？若是只是看performance_schema.tables或者information_schema.INNODB_TABLESPACES，其实依旧是一个无解的问题，由于没法经过这些信息，获得一个相对准确的碎片化程度。
其实在这里（参考连接）的评论中也提到这个问题，我是比较赞同的。

若是要真正获得碎片程度，其实仍是须要重建表来对比实现，这里删除了1/4的数据，理论上就有大概1/4的可用空间，可是上面的查询结果并不能给出一个明确的答案，怎么验证这个答案呢？
这里就要粗暴地优化表了（optimize table fragment_test+analyze table），优化表只是“重整”了碎片，可是系统表的数据并无更新，所以必需要再执行一次分析表 analyze table来更新元数据信息
其实这里也能说明，analyze table只是更新元数据，若是存储空间没有更新（recreated），单纯地analyze table也是没有用的。
对标进行optimize和anlayze以后，这里能够看到，物理空间确实减小了大概1/4的量。

这里其实就是为了说明一个问题：Innodb表没法经过data free来判断表的碎片化程度。

然而这里（参考连接）的测试说明删除数据后data free有明显的变化，这个又是为何，刚特么说没法经过data free来判断表的碎片化程度，如今又说删除数据后data free有明显的变化？？？
其实（参考连接）中有另一个比较有意思的测试，相对用随机删除的方式，采用连续删除的时候（或者是整个表的数据所有删除），这个data free确实会相对准确地体现出来删除数据后表size的变化状况。
这又是为何？其实不难理解，上面已经说了，data free的计算方式，是按照彻底“干净”的区（extent）来作统计的，
若是按照汇集索引连续的方式删除（相对随机删除），那些存储连续数据的区（extent）是能够彻底释放出来的，这些区的空间释放出来以后，会被认为是data free，因此data free此时又是相对来讲准确的。
所以，不少测试，若是想到获得客观的数据，须要尽量多地考虑到对应的场景和测试数据状况。

碎片的衡量
实际业务中，对标的删除或者增删改，不多是按照汇集索引进行批量删除，或者说一旦存在随机性的删除或者更新（页分裂），都会形成必定程度的碎片，而这个碎片化的程度是没法经过data free来衡量的。
那么又如何衡量这个碎片程度呢？
1，本身根据业务进行预估，在可接受程度内进行optimize table，记录optimize table以后的table size变化程度，来衡量一个表在必定时间操做后的碎片化程度，从而来指导是否，或者多久对该表再次进行optimize table
2，采用上述链接中提到的innodb_ruby 这个工具，直接解析表的物理文件，这种方式相对来讲更加直接。不过这个工具本人没来得及测试，理论上是没有问题的。
　这里盗用上述连接中的图片，绿色的是实际使用的空间，中间的黑块就是所谓的碎片或者说是空洞。

 

参考连接：
https://dev.mysql.com/doc/refman/5.7/en/innodb-file-defragmenting.html
https://dev.mysql.com/doc/refman/8.0/en/tables-table.html
https://lefred.be/content/overview-of-fragmented-mysql-innodb-tables/
https://lefred.be/content/mysql-innodb-disk-space/
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_fill_factor