MySQL 8.4 Release Notes
17.11.4 表碎片整理
在次要索引中进行随机插入或删除操作可能会导致索引碎片化。碎片化意味着磁盘上索引页面的物理顺序与记录页面上的索引顺序不符,或者在64页块中有许多未使用的页面被分配给索引。
碎片化的一个症状是表格占用了比它“应该”更多的空间。具体来说,这个问题很难确定。所有InnoDB
数据和索引都存储在B-树中,并且它们的填充因子可能从50%到100%。另一个碎片化的症状是表格扫描,如下所示,需要更多时间:
SELECT COUNT(*) FROM t WHERE non_indexed_column <> 12345;
前面的查询要求MySQL执行完整表扫描,这对于大型表格来说是最慢的一种查询类型。
为了加速索引扫描,您可以定期执行“null”ALTER TABLE
操作,这将导致MySQL重建表格:
ALTER TABLE tbl_name ENGINE=INNODB
您也可以使用ALTER TABLE
执行“null” alter操作,以重建表格。tbl_name
FORCE
ALTER TABLE
和tbl_名
ENGINE=INNODBALTER TABLE
都使用在线 DDL。更多信息,请见第17.12节,“InnoDB 和在线 DDL”。tbl_名
FORCE
另一种方式是使用mysqldump 将表dump到文本文件中,删除表,然后从dump文件中重新加载。
如果对索引的插入总是升序,并且只从末尾删除记录,则InnoDB
文件空间管理算法保证索引中的碎片不发生。