使用sql_variant存儲數據的性能問題

我有一個鍵/值表我用來存儲可以是文本或數字，但沒有別的數據。使用sql_variant存儲數據的性能問題

在初步測試中，在申請時向SQL_VARIANT列citeria，比如我看到可怕性能：

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

所以，很顯然有一些將要打正着這樣的疑問，但我查看查詢的時間超過了10秒，表中只有幾千行。

考慮到我只是要存儲數字或文本數據，使用varchar（255）列會更合理嗎？這樣，選擇性能應該是快速的，我只需要做一個選擇後CAST就可以將數據轉換爲適當的數據類型。

來源

2011-05-16 tbone

這裏有兩種方法來解決這個性能問題：

CAST的標準值，而不是列： SELECT * FROM MY_DATA WHERE
MY_ENTITY_TYPE = 555 AND MY_SQL_VARIANT_COLUMN = CAST（2254 AS NUMERIC ）
將一個索引添加到表中的不同列，看看它是否奇蹟般地解決了這個問題。例如，向MY_ENTITY_TYPE添加一個索引，儘管沒有將條件應用於此列，但它在我的示例中清除了性能問題。

顯然，＃1是兩個更好。

來源

2011-05-16 20:39:18 tbone

但是這個例子並沒有使用「不標準」（使用你有點混淆的術語）。它使用equals運算符，在這種情況下，索引列真的應該有所幫助。假設您的意思是，當您使用與上述略有不同的查詢時，如ALTH增強索引，可提高性能，例如WHERE EntityType！= @typeID。 – 2012-10-19 11:39:08

原諒我，但鍵/值表聽起來像超級常規的數據庫，許多人試圖在某個點或另一個點（我做到了！），它根本不工作。

你確定你不能預測鍵和定義一個表，其中鍵是列和行是相關的值？

來源

2011-05-16 16:35:21 n8wrl

這是爲了存儲在設計時未知的自定義用戶數據，他們將導入任意電子表格等，架構將在元數據中定義。 – tbone 2011-05-16 17:09:03

原諒我，但你的「答案」聽起來像許多人試圖在某個點或另一個點給予的超常規建議！在很多情況下，使用名稱/值對對於「更正」關係表而言，更喜歡「更正」。 – 2012-10-19 11:37:08

使用sql_variant存儲數據的性能問題

回答

相關問題