使用 sql_variant 存储数据的性能问题答案

【问题标题】：Performance issues using sql_variant to store data使用 sql_variant 存储数据的性能问题
【发布时间】：2011-05-17 04:39:18
【问题描述】：

我有一个键/值表，用于存储可以是文本或数字的数据，但仅此而已。

在初步测试中，我看到将 citeria 应用于 sql_variant 列时的性能可怕，例如：

SELECT * FROM MY_DATA WHERE  
MY_ENTITY_TYPE = 555
AND CAST(MY_SQL_VARIANT_COLUMN AS NUMERIC) = 2254

显然，这样的查询会受到一些打击，但我看到查询的时间远远超过 10 秒，表中只有几千行。

考虑到我将只存储数字或文本数据，使用 varchar(255) 列是否更合理？这样，选择性能应该很快，我只需要执行一个 post select CAST 来将数据转换为正确的数据类型。

【问题讨论】：

【解决方案1】：

请原谅，但键/值表听起来像是许多人在某个时候尝试过的超级通用数据库（我试过了！）而且它根本无法正常工作。

您确定不能预测键并定义一个表，其中键是列，行是相关的值？

【讨论】：

【解决方案2】：

这里有两种方法可以解决这个性能问题：

CAST 标准值而不是列： SELECT * FROM MY_DATA WHERE
MY_ENTITY_TYPE = 555 AND MY_SQL_VARIANT_COLUMN = CAST(2254 AS NUMERIC)
为表中的不同列添加索引，看看它是否能神奇地解决问题。例如，为 MY_ENTITY_TYPE 添加索引，尽管没有将条件应用于此列，但它解决了我示例中的性能问题。

显然，#1 是两者中的佼佼者。

【讨论】：

但是该示例没有使用“非标准”（使用您有些令人困惑的术语）。它使用等号运算符，在这种情况下，索引列确实应该有所帮助。大概您的意思是，当您使用与上述稍有不同的查询时，添加索引也提高了性能，例如 WHERE EntityType != @typeID。