Question

我目前正在设计数据库的结构。计划拥有一个巨大的表（让我们称之为Clicks表），拥有数亿行。它的许多列将在其他表中使用外键引用，以减小此庞大表的大小并减少查询时间。

在其他“参考表”中，我计划存储大部分有关点击的数据。因此，当我查看Clicks表时，我只需简单地加入其中一些参考表，以获得我想要了解的点击次数。

第一个问题：这是一个很好的做法 - 如果我稍后会在这个巨大的Clicks表上做很多选择吗？

这些较小的参考表将有几千行，主要是1列，字符串类型。这些字符串的长度介于5-50个字符之间。

我打算做的是当点击时，如果已经存在相同的值，我会检查这些小表，如果没有，那么我将插入它们。

这需要SELECT。

第二个问题：对字符串本身执行搜索并将其编入索引是否更好，或者我是否有另一列包含字符串的MD5结果并查找MD5字符串（带索引）代替？换句话说，字符串的大小是否会影响在简单选择中查找字符串的长度？

我打算像这样做SELECT：

SELECT id FROM table1 WHERE string = $string

有没有更好的方法来实现上述任何一个？

Answer 1

你的设计听起来不错。您希望每个参考表中的字符串都有二级索引。

您的描述不清楚您是否正在执行此操作＆＃34;点击＆＃34;在一次或分批。

除非您迫切需要实时数据，否则我建议您采用批量方法进行此操作。如果你确实需要实时数据，我倾向于提倡＆＃34; streaming-ish＆＃34;方法，通过插入现有表而不是更新来添加新数据。

如果您每天更新数百万行，那么峰值处理期间的锁定操作可能会变得昂贵。如果该表用于分析或报告，则该处理的查询加载也可能会干扰更新。

Answer 2

如果您正在对这些进行哈希处理，那么哈希本身可能比您正在进行哈希处理的字符串更长，从而使其适得其反。您希望哈希那些一直较大并且通常为一个数量级或更多的事物。例如，一个7KB的JSON字符串是一个很好的候选者。计算散列并在索引中查找它会比比较索引中的字符串更快。

您需要做的就是对此进行原型设计，填写代表性的数据量，并了解其运行情况。您的数据库需要进行调整以处理您的工作负载，并且您的架构需要运用到断点，以便您知道在方法崩溃之前可以处理多少数据。

也许这个突破点是1亿条记录。也许它有500亿。没有人知道它将如何在您的硬件上执行，只有您可以通过测试找到。