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 这个工具，直接解析表的物理文件，这种方式相对来说更加直接。不过这个工具本人没来得及测试，理论上是没有问题的。
这里盗用上述链接中的图片，绿色的是实际使用的空间，中间的黑块就是所谓的碎片或者说是空洞。
补充：
早上起来，又想到了另外一种case，就是说随机删除后，剩余空间中出现了“空洞”，这些空洞在写数据的时候，会不会被再次利用？
验证其实很简单，写入200W数据，随机删除50W后，analyze table更新performance_schema,然后继续再写入50W行的数据，如果会利用之前随机删除的空洞空间，那么就不会重新分配物理空间，否则就会重新分配物理空间。
因为聚集索引的Id是自增的，相当于顺序写入，理论上是不会重用之前删除留下的空洞的，测试的结果还是在预期之内的，重新写入50W数据后，表对应的物理文件会有一个很明显的增加。
参考链接：
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
