MySQL下的数据库大小与磁盘上的实际大小之间存在实质性差异

当我检查MySQL下数据库的大小时，得到以下信息：

MariaDB [(none)]> SELECT table_schema "Data Base Name",  sum( data_length + index_length ) / 1024 /  1024 "Data Base Size in MB",  sum( data_free )/ 1024 / 1024 "Free Space in MB"  FROM information_schema.TABLES  GROUP BY table_schema;
+--------------------+----------------------+------------------+
| Data Base Name     | Data Base Size in MB | Free Space in MB |
+--------------------+----------------------+------------------+
| alfresco           |         245.75000000 |      34.00000000 |
| drupal             |         892.15625000 |     216.00000000 |
+--------------------+----------------------+------------------+

当我检查磁盘上的大小时，我得到了：

$ sudo du -h --max-depth=1 /var/lib/mysql/
317M    /var/lib/mysql/alfresco
1.4G    /var/lib/mysql/drupal

如果我结合了Maria DB提供的已用空间和可用空间，并将其与磁盘数字进行比较，则将得到以下结果：

alfresco: DB=279MB  DISK=317MB (+14%)
drupal: DB=1100MB   DISK=1433MB (+30%)

问：磁盘上有这么大的开销是正常的吗/我可以做些什么来减少磁盘开销吗？

仅供参考，我认为运行mysql优化会有所帮助（使用该命令），它确实减小了数据库的大小，但没有更改磁盘上文件的大小。

附加信息：

server:             ubuntu server 10.04 LTS
DB server:          MariaDB
DB engine:          InnoDB v10 (for all tables)
Table collation:    utf8_general_ci
Nb Drupal tables:   416  (0.80MB overhead per table)
Nb Alfresco tables: 84   (0.45MB overhead per table)

如果您使用的是InnoDB表，那么ibdata文件的大小会随着时间的推移而增长。因此，如果发出DELETE语句，则数据库大小将减小，但是ibdata文件将保持不变（而不是减小）。

如果不使用innodb_file_per_tableoption，则回收空间的唯一方法是转储数据库并从转储文件中还原。

但是，如果您使用innodb_file_per_table，则可以发出

ALTER TABLE foo ENGINE=InnoDB;

在太大而无法回收磁盘空间的表上。