参考链接： https://www.cnblogs.com/kerrycode/p/10943122.html

MySQL表碎片化（Table Fragmentation）的原因

关于MySQL中表碎片化（Table Fragmentation）产生的原因，简单总结一下，MySQL Engine不同，碎片化的原因可能也有所差别。这里没有深入理解、分析这些差别。此文仅以InnoDB引擎为主。总结如有不足或错误的地方，敬请指出。

InnoDB表的数据存储在页（page）中，每个页可以存放多条记录。这些记录以树形结构组织，这颗树称为B+树索引。表中数据和辅助索引都是使用B+树结构。维护表中所有数据的这颗B+树索引称为聚簇索引，通过主键来组织的。聚簇索引的叶子节点包含行中所有字段的值，辅助索引的叶子节点包含索引列和主键列。在InnoDB中，删除一些行，这些行只是被标记为“已删除”，而不是真的从索引中物理删除了，因而空间也没有真的被释放回收。

InnoDB的Purge线程会异步的来清理这些没用的索引键和行。但是依然没有把这些释放出来的空间还给操作系统重新使用，因而会导致页面中存在很多空洞。如果表结构中包含动态长度字段，那么这些空洞甚至可能不能被InnoDB重新用来存新的行，因为空间空间长度不足。关于这个你可以参考博客Overview of fragmented MySQL InnoDB tables。

另外，删除数据就会导致页（page）中出现空白空间，大量随机的DELETE操作，必然会在数据文件中造成不连续的空白空间。而当插入数据时,这些空白空间则会被利用起来.于是造成了数据的存储位置不连续。物理存储顺序与逻辑上的排序顺序不同,这种就是数据碎片。

对于大量的UPDATE，也会产生文件碎片化 ， Innodb的最小物理存储分配单位是页(page)，而UPDATE也可能导致页分裂（page split），频繁的页分裂，页会变得稀疏，并且被不规则的填充，所以最终数据会有碎片。

First at all you must understand that Mysql tables get fragmented when a row is updated, so it's a normal situation. When a table is created, lets say imported using a dump with data, all rows are stored with no fragmentation in many fixed size pages. When you update a variable length row, the page containing this row is divided in two or more pages to store the changes, and these new two (or more) pages contains blank spaces filling the unused space.
表的数据存储也可能碎片化。然而数据存储的碎片化比索引更加复杂。有三种类型的数据碎片化。##下面部分内容摘自【高性能MySQL】##

行碎片（Row fragmentation）

这种碎片指的是数据行被存储为多个地方的多个片段。即使查询只从索引中访问一行记录。行碎片也会导致性能下降。

行间碎片（Intra-row fragmentaion）

行间碎片是指逻辑上顺序的页，或者行在磁盘上不是顺序存储的。行间碎片对诸如全表扫描和聚簇索引扫描之类的操作有很大的影响，因为这些操作原本能够从磁盘上顺序存储的数据中获益。

剩余空间碎片（Free space fragmentation）

剩余空间碎片是指数据页中有大量的空余空间。这会导致服务器读取大量不需要的数据。从而造成浪费。

对于MyISAM表，这三类碎片化都有可能发生。但InnoDB不会出现短小的行碎片；InnoDB会移动短小的行并写到一个片段中。InnoDb会移动短小的行并重写到一个片段中。

官方文档14.15.4 Defragmenting a Table关于降低表的碎片化介绍如下（非常简洁，MySQL官方文档往往简洁，信息量大，但是没有详细介绍）：
Random insertions into or deletions from a secondary index can cause the index to become fragmented. Fragmentation means that the physical ordering of the index pages on the disk is not close to the index ordering of the records on the pages, or that there are many unused pages in the 64-page blocks that were allocated to the index.
One symptom of fragmentation is that a table takes more space than it “should” take. How much that is exactly, is difficult to determine. All InnoDB data and indexes are stored in B-trees, and their fill factor may vary from 50% to 100%.

从二级索引中随机插入或删除可能会导致索引碎片化。碎片意味着磁盘上索引页的物理排序不接近页面上记录的索引排序，或者64页块中有许多未使用的页面被分配给索引。
碎片化的一个症状是表格占用的空间比“应该”占用的空间多。多少确切地说，很难确定。所有 InnoDB 数据和索引都存储在 B-trees 中，它们的 fill factor 可能在50％到100％之间变化。碎片的另一个症状是像这样的表扫描需要比“应该”花费更多的时间

确定数据库中碎片化严重的表

查询数据库的表碎片化情况。或者空闲空间超过10M大小的表。这个可以根据自己的需求设定查询条件。在此略过。

SELECT
      CONCAT('OPTIMIZE TABLE ', table_schema, '.', table_name, ';') AS 'OPTIMIZE TABLE',
      ENGINE,
      ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) AS SIZE_MB,
      ROUND(DATA_FREE / 1024 / 1024, 2) AS FREE_SIZ_MB
FROM
      information_schema.TABLES
WHERE
      DATA_FREE > 10 * 1024 * 1024
      AND TABLE_SCHEMA NOT IN (
            'mysql',
            'information_schema',
            'performance_schema',
            'sys'
      )
ORDER BY
      FREE_SIZ_MB DESC;

执行结果示例

复制结果中的sql语句进行执行即可

OPTIMIZE TABLE scrs.jq_tvpm_vehiclelog_part;

执行结果示例