根据大小分离 VARCHAR 值是否有性能提升？

Question

我正在与一个试图实施 EAV 系统的团队合作。他们决定按类型拆分属性值表，并且他们正在讨论针对不同大小范围的 varchar 使用不同的表。

前任：

• table_1 - 最多 varchar(10)
• table_2 - varchar(11) 到 varchar(500)
• table_3 - varchar(501) 到 varchar(MAX)

我一直认为varchar只会使用它需要的大小。

你知道这是否会提高性能，是否值得额外的编码/逻辑？

Answer 1

我的直觉是，您获得的任何性能提升都不值得因需要强制分离并在应用程序逻辑中执行多次查找而带来的额外麻烦（以及潜在的错误）。

如果您有很多小值并且只查询它们而其余的都没有，您会看到一些性能提升，因为更多的行将适合每个页面，因此总体而言需要在 RAM 中处理或从磁盘读取给定的页面更少询问。一旦您一次性（或只是混合）需要所有属性，则需要单独查询多个表或通过 UNION 查询多个表，这种好处将被吹走。

当然，唯一可以确定的方法是建立一个相当现实的大型数据集，并针对您正在考虑的安排运行一些性能测试。但我非常怀疑你会看到任何值得额外复杂性的变化。如果您的数据可以以更合乎逻辑的方式（即您的业务逻辑隐含的方式）进行拆分，那么我建议您查看数据分区，特别是如果您可以将分区拆分到不同的驱动器上。每当您发现自己正在考虑潜在的复杂性负载优化（包括分区）时，请务必返回并重新考虑您的整体数据结构，并确保它不违反您的业务逻辑，并检查您的硬件是否足以满足您期望的负载 - 而事实并非如此保证您可能会通过研究这些核心领域而获得更显着的收益。

Answer 2

你根本不会有任何性能提升。

快速思考，根本不是详尽的分析：

• 在某些时候，您需要联合这些以获得单一视图，然后一切都变成 varchar(max)
• 你如何预先决定长度？
• 索引搜索值？你不能索引 > 900 字节
• 在 EAV 中滚动您自己的“唯一”约束就够糟糕了，无需拆分到多个表

寻找EAV 反模式：有几篇关于如何避免 EAV 的文章

Answer 3

听起来他们正在尝试优化 EAV 以进行查找。然而，这显然听起来他们并不是试图针对已描述的缺陷优化系统，而是试图通过巫毒猜测进行优化。

提醒他们优化的第一条规则是分析，就像 David Spillett 所说的那样，直到 EAV 中有几亿行（考虑到我所知道的大多数实体至少有 15 个属性 en-toto，所以你只会得到像一个几千万个实体）然后配置文件，您无法知道这会产生任何影响。

我会说“不，这不会像他们想象的那样受益”并且更好的分区可能是大约 50 个字符和 100 个字符而不是 10 个和 500 个字符。但这只是一个猜测。

但请注意，它会产生他们想要的效果，因为它将允许更好的索引性能（作为一般经验法则，所有数据分区都应该提供比非分区更好的索引性能）