SQL插入性能問題

我有這個表電話簿的SQL Server 2005：SQL插入性能問題

username(PK) Serial(PK) contact_name contact_adr  contact_email contact_phone 
bob   1   Steve   12 abc street [email protected] 1234   
bob   2   John   34 xyz street [email protected] 5345   
bob   3   Mark   98 ggs street [email protected] 1234   
patrick  4   lily   77 fgs street [email protected] 1234   
patrick  5   mily   76 fgs street [email protected] 1234   
von   8   jim   6767 jsd way  [email protected]  4564

現在你可以看到電話簿存儲同一用戶的所有聯繫人在一起。這種方式存儲有我無法避免的優點。

我的問題是：如果我在所有用戶的表中有1億個條目，我將來在上面的表中插入會非常昂貴嗎？

由於SQL引擎需要找到實際的位置在哪裏輸入數據（我的意思是根據該用戶名）

我有一個百萬行的測試，我看不出有明顯的問題。

我在問有沒有人對我有這樣的經驗或建議？

感謝

來源

2010-12-06 kheya

您將使用哪種SQL軟件？（另外，'PK'意味着在列上有一個唯一的索引，所以我猜這是你用「username」表示的外鍵（FK），'serial'是你真正的主鍵（PK）） – 2010-12-06 19:20:21

帶有重複數據的主鍵？ – Sathya 2010-12-06 19:20:53

我錯過了PK。 PK是（用戶名+串行） – kheya 2010-12-06 19:37:46

一個在數據庫設計的首要原則是數據非冗餘：你有相同的數據重複很多次你的數據庫表的設計不符合這一原則。一個合理的解決方案是爲用戶創建單獨的表格，爲聯繫人創建單獨的表格以及在用戶和聯繫人之間建立關係的表格。

來源

2010-12-06 19:21:10

用戶名是FK。我在另一個表中有用戶名和帳戶詳細信息 – kheya 2010-12-06 19:42:52

它取決於底層數據庫。每個實現都有不同的東西。

但是！如果您在該表上使用索引，並且其中有許多，許多，許多行，性能幾乎肯定會受到影響。

來源

2010-12-06 19:21:58 darioo

首先，用戶名似乎並不是表格本身的主鍵。如果你想讓它工作，你可能必須結合其他領域使用它。此時，我寧願使用您的serial列作爲主鍵，並在username上有索引來回答查詢有效地獲取bob的聯繫人。

隨着您的表的增長，您插入的內容肯定會變慢。但我不認爲這樣做會太慢，以至於無法遵循這種方法。

來源

2010-12-06 19:22:21

您不能強制數據一起存儲。是否在插入時重新對序列進行排序？你如何確保數據「一起存儲」？

如果你的意思是把所有這些數據放在一張表中，那麼它確實取決於你的索引結構。表格上的索引越多，非常插入的處理就越多。由於用戶表通常被嚴重查詢並且很少插入（相對），因此通常會對其進行大量索引，在這種情況下，插入操作可能會很慢。答案與幾乎所有數據庫問題一樣：「這取決於」。

來源

2010-12-06 19:33:22

最適合地址簿的方法是NOSQL哈希表。 PK上不需要索引。該算法返回可以找到由PK標識的行的「頁面」。用戶的地址簿也作爲非規範化關係與用戶一起存儲。插入開銷可以忽略不計。當已知PK時，哈希-PK針對插入/檢索進行了優化。非常適合OLTP系統。現在，如果你想做一些事情，比如說誰知道誰是誰，那麼給定用戶的聯繫人需要與所有其他用戶的聯繫人相關聯，那麼你就有不同的蠕蟲病毒。但是一個簡單的地址簿應用程序，一個給定用戶的聯繫人對該用戶保持「私有」，那麼散列主鍵系統是非常好的。

來源

2010-12-06 19:48:18 Tim

SQL插入性能問題

回答

相關問題