字符串大小会影响 MySQL 中的选择查询速度吗？答案

【问题标题】：Does string size affects select query speed in MySQL?字符串大小会影响 MySQL 中的选择查询速度吗？
【发布时间】：2017-11-02 16:07:56
【问题描述】：

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

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

第一个问题：在速度方面这样做是否是一个好习惯 - 如果我稍后要在这个巨大的 Clicks 表上进行大量选择？

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

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

这需要一个 SELECT。

第二个问题： 最好对字符串本身执行搜索并为其编制索引，还是我应该有另一列包含字符串的 MD5 结果并查找 MD5 字符串（带索引）反而？换句话说，字符串的大小是否会影响在简单选择中查找字符串的长度？

我打算做这样的选择：

SELECT id FROM table1 WHERE string = $string

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

【问题讨论】：

【解决方案1】：

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

您的描述不清楚您是一次“点击”还是批量进行。

除非您对实时数据有迫切的需求，否则我会推荐这种操作的批处理方法。如果您确实需要实时数据，我倾向于提倡“流式”方法，即通过插入现有表而不是更新来添加新数据。

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

【讨论】：

【解决方案2】：

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

您需要做的是对此进行原型制作，用具有代表性的数据量填充它，然后查看它的性能。您的数据库需要调整以处理您的工作负载，并且您的架构需要运行到临界点，以便您知道在您的方法崩溃之前可以处理多少数据。

也许突破点是 1 亿条记录。也许是500亿。没有人知道它在你的硬件上的表现如何，只有你通过测试才能知道。

【讨论】：