症状
ApsaraDB RDS for MySQL 5.7 インスタンスで以下のクエリを実行すると、上位の結果のほとんどに、DATA_FREE の値として同一の大きな数値が表示されます。これらのテーブルはすべて information_schema データベースに属しています。ただし、この値は当該テーブルの実際のディスク断片化状況と一致しません。
SELECT TABLE_SCHEMA, TABLE_NAME, DATA_FREE FROM INFORMATION_SCHEMA.TABLES ORDER BY DATA_FREE DESC LIMIT 10;実行例の出力：
+--------------------+-----------------+-----------+
| TABLE_SCHEMA | TABLE_NAME | DATA_FREE |
+--------------------+-----------------+-----------+
| information_schema | COLUMNS | 8388608 |
| information_schema | EVENTS | 8388608 |
| information_schema | OPTIMIZER_TRACE | 8388608 |
| information_schema | PARAMETERS | 8388608 |
| information_schema | PARTITIONS | 8388608 |
| information_schema | PLUGINS | 8388608 |
| information_schema | PROCESSLIST | 8388608 |
| information_schema | ROUTINES | 8388608 |
| information_schema | TRIGGERS | 8388608 |
| information_schema | VIEWS | 8388608 |
+--------------------+-----------------+-----------+根本原因
これは MySQL 5.7 における既知のバグです。
information_schema 内の一部のテーブル（例：COLUMNS、EVENTS）は InnoDB ストレージエンジンを使用しており、innodb_temporary 表領域（対応するファイルは ibtmp1）に一時テーブルとして格納されます。このバグにより、MySQL は各テーブルごとの断片化状況ではなく、ibtmp1 ファイル全体の空き領域を、これらのテーブルそれぞれの DATA_FREE 値として報告します。
これを確認するには、以下のクエリを実行してください：
SELECT TABLESPACE_NAME, FILE_NAME, ENGINE, DATA_FREE FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary';実行例の出力：
+------------------+-----------+--------+-----------+
| TABLESPACE_NAME | FILE_NAME | ENGINE | DATA_FREE |
+------------------+-----------+--------+-----------+
| innodb_temporary | ./ibtmp1 | InnoDB | 8388608 |
+------------------+-----------+--------+-----------+DATA_FREE の値が完全に一致することから、表示されているのは各テーブルの実際のディスク断片化ではなく、ibtmp1 ファイルの空き領域であることが確認できます。
ソリューション
これは、MySQL 5.7 の既知の問題に起因する表示上のバグであり、無視しても構いません。
この問題を防止するには、メジャーエンジンバージョンを MySQL 8.0 にアップグレードします。詳細については、「ApsaraDB RDS for MySQL インスタンスのメジャーエンジンバージョンをアップグレードする」をご参照ください。
ibtmp1 ファイルが占有しているストレージ領域を解放するには、RDS インスタンスを再起動してください。再起動後、ibtmp1 は innodb_temp_data_file_path パラメーターで定義された初期サイズにリセットされます。