Question

客户端只有大约1000行数据（当然是最新的），只是在其中一个表中丢失了。做一些取证，我发现所有表中所有其他行中的“last_updated_date”也设置为与删除发生的大致相同的时间。这不是他们较大的表格之一。

其他一些奇怪的事情是，上周的mysqldumps都是 exact 相同的大小 - 10375605093字节。以前的转储每个增长约0.5GB。 MySQL转储命令是标准的：

/path/to/mysqldump -S /path/to/mysqld2.sock --lock-all-tables -u username -ppassword database > /path-to-backup/$(date +%Y%m%d)_live_data.mysqldump

框上的df -h显示每个目录中有足够的空间（至少50％）。

数据丢失加上他们的转储大小没有增加的事实让我担心我们在某种程度上会在MySQL中遇到一些硬编码限制（上帝，我希望我错了），数据正在被破坏。有没有人听说过这样的事情？我们如何解释mysqldump大小？

Answer 1

如果您正在进行多个多演出转储并且中途耗尽空间，则50％的可用空间并不意味着什么。除非你在转储中存储二进制数据，否则它们是可压缩的，所以我建议在输出到文件之前通过gzip管道mysqldump的输出：

mysqldump .... | gzip -9 > /path_to_backup/....

MySQL本身没有任何任意限制，表示“在X演出之后不再有”，但是正在运行的平台强加了限制，detailed here。

Answer 2

MySQL可以处理的数据量没有硬编码限制。