最近有个项目，上位机获取下位机上报的数据。由于上报频率频繁，数据量大，导致数据增长过快。磁盘使用率很高。为了节省成本，定期进行数据备份，通过delete删除表记录。很明显，删除已经执行了，但是表文件的大小并没有减少。百思不得其解，项目中使用的是Mysql作为数据库。对于表，一般是表结构和表数据。表结构占用的空间比较小，一般是表数据占用的空间。当我们使用delete删除数据时，表中的数据记录确实被删除了，但是表文件的大小没有变化。MySQL数据结构用过mysql的人一定听说过B+树。MySQLInnoDB使用B+树作为存储数据的结构，也就是常说的索引组织表，数据按页存储。因此，在删除数据时，会出现两种情况：删除数据页中的部分记录删除整个数据页的内容表文件大小没有变化，与MySQL设计相关标记为删除的记录称为可重用位置。如果要插入ID介于300和700之间的记录，此位置将在以后重复使用。可以看出磁盘文件的大小并不会减少。一般删除整页数据也会删除记录标记，数据会在这个位置重新使用。与删除听写记录不同的是，删除整页记录时，当后面插入的数据不在原来的范围内时，该位置可以重复使用。如果只是删除听写记录，需要插入数据匹配删除记录的位置，才能重新使用。所以无论是数据行还是数据页的删除，都标记为已删除，以便重新使用，所以文件不会减少。那我们怎样才能让桌子的尺寸变小呢？DELETE只是删除数据标志，并不整理数据文件。当插入新数据时，设置为删除标志的记录空间将被再次使用。您可以使用OPTIMIZETABLE回收未使用的空间，并对数据文件进行碎片整理。OPTIMIZETABLE表名；注意：OPTIMIZETABLE仅适用于MyISAM、BDB和InnoDB表。另外，还可以通过ALTERTABLEALTERTABLE表名ENGINE=INNODB重建表有人会问OPTIMIZETABLE和ALTERTABLE有什么区别？altertabletengine=InnoDB（即recreate），optimizetablet等于recreate+analyzeOnlineDDL。最后说一下OnlineDDL。dba的日常工作之一肯定是ddlchange，会锁表。这可以说是dba心中永远的痛，尤其是在执行ddl变更时，导致库上大量线程处于“Waitingformetadatalock”状态。所以在5.6版本之后引入了OnlineDDL。在OnlineDDL推出之前，DDL的执行方式主要有两种：copy和inplace。inplace方法也叫（快速创建索引）。与copy方法相比，inplace方法不复制数据，所以速度更快。但是这种方式只支持增删索引两种方式，而且和copy方式一样需要一路锁表，实用性不是很高。与前两种方式相比，Online方式不仅可以读，还支持写操作。执行在线DDL语句时，使用ALGORITHM和LOCK关键字。这两个关键字在我们的DDL语句的末尾，用逗号分隔。示例如下：ALTERTABLEtbl_nameADDCOLUMNcol_namecol_type,ALGORITHM=INPLACE,LOCK=NONE;ALGORITHMoptionINPLACE:replace：直接对原表进行DDL操作。COPY：复制：使用临时表的方式克隆一个临时表，在临时表上执行DDL，然后将数据导入临时表，重命名等，这期间需要两倍的磁盘空间来支持这样操作。在执行期间，表不允许DML操作。DEFAULT：默认方式由MySQL自己选择，首选INPLACE方式。LOCKoptionSHARE：共享锁，执行DDL的表可以读，不能写。NONE：没有限制，可以读写执行DDL的表。EXCLUSIVE：独占锁，执行DDL的表不可读写。DEFAULT：默认值，即DDL语句中没有指定LOCK子句时使用的默认值。如果将LOCK的值指定为DEFAULT，则交给MySQL子句来决定是否对表加锁。不建议使用。如果确定你的DDL语句不会锁表，可以不指定lock或者指定其值为default，否则建议指定其锁类型。执行DDL操作时，可能未指定ALGORITHM选项。这时MySQL会自动按照INSTANT、INPLACE、COPY的顺序选择合适的模式。您还可以指定ALGORITHM=DEFAULT，这具有相同的效果。如果指定了ALGORITHM选项但不支持，会直接报错。OPTIMIZETABLE和ALTERTABLE表名ENGINE=INNODB都支持OlineDDL，但是还是建议在业务流量小的时候使用summarydelete。删除数据时，实际上并没有删除对应的数据行，只是标记为可用。复用状态，所以表空间不会变小。您可以在删除数据（OPTIMIZETABLE或ALTERTABLE）后重建表以快速减小表的大小。5.6版本以后，建表已经支持Online操作，但是最好在业务不多的时候使用。
