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

Question

我有一个键/值表，用于存储既可以是文本也可以是数字的数据，但没有其他任何数据。

在初步测试中，我看到了在将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转换就可以将数据转换成适当的数据类型。

Answer 1

以下是解决此性能问题的两种方法：

1. 转换为标准值，而不是列: SELECT *从MY_DATA

MY_ENTITY_TYPE = 555和MY_SQL_VARIANT_COLUMN = CAST(2254为数值)

• 将索引添加到表中的另一列，并查看它是否神奇地解决了问题。例如，向MY_ENTITY_TYPE添加索引，尽管没有将标准应用于本专栏，但它消除了我的示例中的性能问题。

显然，#1是两者中最好的。

Answer 2

原谅我，但是key/value表听起来像是uber-general DB --很多人在某个时候尝试过(我做了！)结果一点也不管用。

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