MyIsam MRG——管理独特性的最佳实践答案

【问题标题】：MyIsam MRG -- best practices managing uniquenessMyIsam MRG——管理独特性的最佳实践
【发布时间】：2017-11-16 19:24:14
【问题描述】：

MRG 表包含 1B+ 行，分布在几个较小的表中。额外的观察被添加到 MRG 表中，这将它们添加到最后一个基础表中。

由于某种原因，似乎有几个重复的行共享相同的主键。我知道这是 MRG 表的一个限制，在我们的例子中它并不是真正的问题（它只是意味着无用的冗余）。我们认为重复项是在系统崩溃后插入的，因此在插入存档之前从临时表中删除重复项的应用程序代码未正确处理重新处理。

话虽如此，是否有一套最佳实践来保持唯一性，并且不需要太多的处理时间？

【问题讨论】：

我怀疑你的问题是否会引起很大的关注。我上一次使用 MRG 是在 15 年前，从那时起就没有听说有人使用它。 MyISAM 正在消失，MRG 也随之消失。 PARTITIONing 主要是它的替代品；但即使它也没什么用。你为什么用 MRG 而不是一张大桌子？
每天更新数百万行。使用一组较小的表可以实现并行化。坚持使用 myIsam，因为它允许更快、更紧凑的备份。但是，是的，很可能在不久的将来切换到分区的 innodb。同时使用具有主键的统一表来强制唯一性。不理想，但能胜任
MyISAM 处理分区，因此进行唯一性检查。
你能在分区表上并行化进程吗？使用 MRG 框架，可以轻松发出不同的 UPDATE 命令，每个基础表一个。完全不清楚这可以通过分区来完成......
对于较新版本的 MySQL，您可以在语句中指定分区。你有什么版本？但是，尚不清楚您是否获得任何好处。如果您已经拆分为多个线程，它可能会在不尝试指定哪个分区的情况下工作。即使有十亿行，我也不一定会为了性能而分区（或MERGE）。

【解决方案1】：

您将始终面临重复的风险。

...MERGE 表不能对基础表集强制唯一性。

不要使用 MERGE 表。 MERGE 仅适用于 MyISAM 和 you shouldn't be using MyISAM。

改为使用PARTITIONING。您可以在给定表的所有分区中强制唯一性。

【讨论】：