我在重新导入由 mysqldump 生成的数据库转储时遇到问题。我使用 order-by-primary 选项运行 mysqldump，并让它在具有唯一键的表上运行（并且没有显式主键，因此它按该唯一键排序）。在这种情况下，我的目标是重新创建表，使唯一键成为主键。
这个转储花了很长时间（大约 10 天），再次运行它会很痛苦。我尝试重新导入转储（使用适当的架构更改），但 mysql 在中途窒息。我查看了转储文件，在它窒息的地方 - 看起来有人将垃圾邮件直接插入到转储文件的文本中。
幸运的是，看起来损坏是孤立的，我能够在垃圾之前和之后看到钥匙。
tl; 博士：如果我只是拼接垃圾，我不知道前一个和后一个之间会丢失多少键 - 转储按那个唯一键排序，因此在这方面它让生活更轻松。mysql 是否有办法检索索引中两个条目之间的所有行？
密钥是 32 个字符的十六进制字符串，存储在 CHAR(32) 类型列中。我很确定我不能在字符串上使用 < 或 > 运算符......所以有什么建议吗？
Sorting the mysqldump on the primary key (or unique key) is what made it take so long. Ten days is pretty unbelievable, though.
Doing a sort like this is useful only when you want to backup a MyISAM table and restore it to an InnoDB table. Is this what you're doing?
MySQL certainly does have a way to dump subsets of a table. Check out the --where option of mysqldump. This should allow you to back up the rows that got corrupted.
And yes, you can use < and > on strings in SQL. You can also use the BETWEEN predicate.
我的第一个问题是，垃圾邮件如何进入您的数据库转储并销毁它？
我猜它来自您的一个数据列，对吗？你能说明这封电子邮件是如何破坏你的转储结构的吗？
也许是某种标头注入导致转储在不应该有的地方插入换行符，我不知道。无论如何，在我看来，清除它是第一要务。