有效的鍵/值表

我需要一個表來存儲鍵/值對（如Windows註冊表）。以下是我有：有效的鍵/值表

CREATE TABLE REG   
(      
    ID VARCHAR(255) NOT NULL, 
    DATA VARCHAR(1024), 
    PRIMARY KEY(ID)   
);

我使用SQL Server 2008 R2中，2008年和2005年

誰能提供更effecient主意存儲鍵/值對。

我存儲這樣的鍵：

/USER/REX/AUTO_LOGIN = 「T」

/USER/REX/MESSAGE/1 = 「這是一個較長的消息」

在大約10000條記錄我已經看到了性能問題。

來源

2012-04-27 GenuineRex

性能問題在哪裏呢？將主鍵設置爲ID時，SQL Server應對該列進行索引並查詢它，但在10k行仍應該非常快。假設你正在做如下查詢：'從註冊表中選擇* WHERE id ='/ USER/REX/AUTO_LOGIN'。如果你開始投擲可能會影響事物的通配符... – Windle 2012-04-27 16:36:41

我正在使用此查詢：SELECT DATA FROM REG WHERE ID =？ – GenuineRex 2012-04-27 16:37:42

和這個：UPDATE REG SET DATA =？ KEY =？ – GenuineRex 2012-04-27 16:38:00

您可以引入一個額外的列，它是密鑰名稱的哈希值;例如「/ USER/REX/AUTO_LOGIN」可能會散列到102454.然後，您可以在哈希列（或哈希列和鍵名列上的複合索引）上添加索引，並將其包含在任何查詢的where子句中;例如

SELECT DATA 
FROM REG 
WHERE HASH = 102454 and ID = '/USER/REX/AUTO_LOGIN'

在搜索上的int列應遠比查詢varcharID柱更高效，並應具有相同的散列值，然後將被檢查用於匹配縮小到幾行的效果值爲ID。

來源

2012-04-27 16:33:26 Adamski

對不起，但這對我來說聽起來像是一個壞主意，原因如下：（1）二級索引在集羣表中非常昂貴（您可以將它設爲非集羣，但也有一個價格）。（2）你無法避免使用ID索引（因爲它是PK），所以爲什麼不使用_it_？我完全不相信哈希上的非複合索引實際上會更快（它更緊湊，但會出現「誤報」）。 OTOH，在散列和ID上合成完全沒有意義。你真的有這種技術的實踐經驗嗎？你是否對現實的數據量進行了基準測試？ – 2012-04-28 04:01:43

我會避免使用varchar(255)作爲我的主鍵，選擇了一個唯一索引替代：

CREATE TABLE REG (
    id bigint identity not null, 
    key VARCHAR(256) NOT NULL, 
    DATA VARCHAR(1024), 
    PRIMARY KEY(ID) 
); 

create unique index reg_key on REG(key);

來源

2012-04-27 16:34:29 dasblinkenlight

我想過這個，但後來我需要一個關鍵索引，任何SELECT查詢都會讀取關鍵字上的索引，然後必須根據主鍵進行查找。這可能會使更新速度更快，但是，一旦我擁有內存中的PK。 – GenuineRex 2012-04-27 16:36:05

@GenuineRex無論如何，我會試一試：在集羣PK索引中使用不同長度的大數值看起來不太合適，儘管我可能在那一個上是錯誤的。 – dasblinkenlight 2012-04-27 16:45:14

有效的鍵/值表

回答

相關問題