sql - 考虑可扩展性时，为什么连接不好？

Question

为什么连接不好或“慢”。我知道我不止一次听到过这个。我找到了这句话

The problem is joins are relatively slow, especially over very large data sets, and if they are slow your website is slow. It takes a long time to get all those separate bits of information off disk and put them all together again.

source

我一直认为他们很快，尤其是在查找 PK 时。为什么他们“慢”？

Answer 1

可扩展性就是预计算(缓存)、分散或将重复工作减少到最基本的部分，以最大限度地减少每个工作单元的资源使用。为了很好地扩展，您不需要大量做任何事情，并且确保您实际做的事情尽可能高效地完成。

在这种情况下，加入两个单独的数据源当然相对较慢，至少与不加入它们相比是这样，因为这是您需要在用户请求时实时完成的工作。

但请记住，替代方案是不再拥有两个单独的数据；您必须将两个不同的数据点放在同一条记录中。您无法将两个不同的数据组合在一起而不产生任何结果，因此请确保您了解其中的权衡。

好消息是现代关系数据库擅长连接。如果数据库使用得当，您不应该认为连接速度会很慢。有许多可扩展性友好的方法可以采用原始连接并使其速度快得多:

• 连接代理键(自动编号/身份列)而不是自然键。这意味着连接操作期间的比较更小(因此更快)
• 索引
• 物化/索引 View (将其视为预先计算的联接或托管反规范化)
• 计算列。您可以使用它来散列或以其他方式预先计算联接的关键列，这样联接的复杂比较现在要小得多，并且可能预先索引。
• 表分区(通过将负载分散到多个磁盘或将表扫描限制为分区扫描来帮助处理大型数据集)
• OLAP(预先计算某些类型的查询/连接的结果。这并不完全正确，但您可以将其视为通用非规范化)
• 复制、可用性组、日志传送或其他机制，让多台服务器响应同一数据库的读取查询，从而在多台服务器之间扩展工作负载。
• 使用 Redis 等缓存层来避免重新运行需要复杂连接的查询。

我什至可以说关系数据库存在的主要原因是为了让您能够有效地进行连接^*。它当然不仅仅是存储结构化数据(您可以使用 csv 或 xml 等平面文件结构来实现这一点)。我列出的一些选项甚至可以让您提前完全构建连接，因此在发出查询之前结果就已经完成 - 就像您对数据进行了非规范化一样(诚然，以较慢的写入操作为代价)。

如果连接速度很慢，则可能没有正确使用数据库。

只有在这些其他技术失败后才应进行反规范化。真正判断“失败”的唯一方法是设定有意义的绩效目标并对照这些目标进行衡量。 如果您还没有进行测量，那么现在考虑反规范化还为时过早。

<小时/>

_{* 也就是说，作为与单纯的表集合不同的实体存在。真正的 RDBMS 的另一个原因是安全的并发访问。}