我在UNIX服务器上管理许多数据库，并使用mysqldump对这些数据库进行每日备份。由于（其中一些）这些数据库很大（20 GB），因此我通常使用bzip2缩回备份.SQL文件，以获取压缩BZ2文件。
作为备份过程的一部分，我检查了新备份文件的大小是否大于或等于先前备份文件的大小 - 我们每天都在这些数据库中添加数据，但很少删除来自这些数据库的数据。
检查备份文件大小的检查是备份质量的检查 - 鉴于我们的数据库主要仅在大小上生长，如果新备份小于旧备份，则意味着a）已删除某些东西从数据库中（在这种情况下，我应该检查什么...）或b）备份出现问题（在这种情况下，我应该检查为什么...）。
但是，如果我比较BZ2文件的大小 - 例如，使用stat %s的比较（使用test），即使数据库的尺寸增加了，BZ2文件可能会缩小 - 大概是由于更有效的压缩。
所以 - 如何比较备份文件的大小？
- 一个选项是将先前的备份文件从.bz2解压缩到.sql，并比较这些.sql文件的尺寸。但是，鉴于这些是很大的文件（20 GB），因此压缩/减压可能需要一段时间...
- 另一个选项是将先前的备份文件保持为.sql，然后再次进行.sql文件的比较。这是我首选的选择，但需要一些小心，以确保我们不会最终出现很多.sql文件 - 因为这会很快吞噬我们的硬盘驱动器。
另外，SO社区中的某人可能有一个更好或更明亮的想法...？
可以将输入文件分为部分（例如100MB块），并分别比较它们。由于大小实际上也可能在不同的输入中保持不变，因此您通常不应将其用于寻找差异 - 而是使用CMP之类的内容来查看文件是否不同。
也可以将单个部分的BZ2文件归结在一起，并获得一个完美有效的多流BZ2文件，该文件可能会在没有任何问题的情况下再次不压缩。您可能需要研究PBZIP，这是BZIP的并行实现，并准确地使用此机械师将并行BZIP用于多流BZ2文件，以加快SMP/Multi Core Systems上的过程。
关于为什么我建议将文件分为部分：取决于您的MySQL设置，您的某些零件可能永远不会更改，并且数据实际上可能大部分时间都在结束时 - 如果您可以确保确保这，您只需要比较整个转储的小部分，这会加快过程的速度。
仍然要注意，整个数据可能会更改而无需添加或删除任何内容，因为MySQL可能会在内存中求解数据（例如，优化命令可能会导致此）
）如果您使用InnoDB，则可以将数据拆分的另一种方法 - 在这种情况下，您可以告诉MySQL（使用my.cnf）每个表使用一个文件，因此您可以a）单独使用这些文件，并仅比较表可能实际上已更改的表（如果您在某些表中有静态数据）和/或b）保存表文件的最后修改日期，并比较事先（同样，这仅在您有以防万一只有静态数据的表）