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插入性能问题

回答

相关问题