在 SQL Server 中存储大型数据集的最佳方法？答案

【问题标题】：Best way to store large dataset in SQL Server?在 SQL Server 中存储大型数据集的最佳方法？
【发布时间】：2009-08-07 00:57:23
【问题描述】：

我有一个数据集，其中包含一个字符串键字段和最多 50 个与该信息相关的关键字。将数据插入数据库后，写入 (INSERTS) 将非常少，但主要是查询一个或多个关键字。

我已阅读基于 MySQL 的“Tagsystems: performance tests”，似乎 2NF 似乎是实现此功能的好方法，但是我想知道是否有人有使用 SQL Server 2008 和非常大的数据集执行此操作的经验。

我最初可能有 100 万个关键字段，每个字段最多可以有 50 个关键字。

会是一个结构

keyfield, keyword1, keyword2, ... , keyword50

成为最好的解决方案或两张桌子

keyid
keyfield
| 1
|
| M
keyid
keyword

如果我的查询主要是要查找具有一个或多个关键字的结果，是否会更好？

【问题讨论】：

还应该添加查询不是 LIKE 查询，而是直接像关键字 = 'helloworld'

标签： sql sql-server database sql-server-2008

【解决方案1】：

我会进一步规范化。

您应该有一个具有整数主键列的唯一关键字表。然后，另一个具有 KeyField 和 KeyWordId 的关联表。

KeyWords
----------
KeyWordId Int Identity(1,1)
KeyWord VarChar(200)

KeyFieldKeyWords
----------------
Keyfield Int
KeyWordId Int

如果有 100 万个键域，每个键域有 50 个关键字，那就是 5000 万行。如果你的表有 2 列，每列都是一个整数，那么性能会有很大差异。

【讨论】：

这就是我实现它的方式，它似乎是在 SQL Server 中存储此类数据的最快方式

【解决方案2】：

标准化可能是您更好的选择，但只有模拟工作负载才能确定。您正在比较 50 个越来越稀疏的索引，每个索引有 100 万行，而 1 个索引有 5000 万行。我怀疑如果我是 MS 的天才，我会编写一个算法来搜索一个索引，我会在一次走多远的时候找到我正在寻找的值。

但如果有 50 个索引，我就必须扫描 50 个索引。

此外，在非规范化架构中，第 1 列将具有高质量索引，第 50 列将具有低选择性，并且可能导致扫描而不是索引查找。

【讨论】：

+1 表示关于选择性的评论，可能影响最大

【解决方案3】：

只要您有正确的索引，50M 行就不算多。我会把它存储为

CREATE TABLE mytable (
    keyfield nvarchar(200),
    keyword nvarchar(200),
    CONSTRAINT PK_mytable PRIMARY KEY(keyfield, keyword)
)

当然还有索引关键字列。如果您从不需要获取某个键域的所有关键字，则只需更改主键中的顺序即可避免额外的索引

编辑：我太累时不应该发帖。就是这样。

【讨论】：

但我有 50 个关键字而不是一个，除非我误解了你的解释。

【解决方案4】：

我无法想象像

这样的查询

SELECT  keyfield FROM mytable
  WHERE keyword1 in (value1, value2, ...)
     OR keyword2 in (value1, value2, ...)
     OR keyword3 in (value1, value2, ...)
     ....
     OR keyword5 = in (value1, value2, ...)

您的第二个选项看起来好多了 SELECT keyfield FROM mytable WHERE 关键字 in (value1, value2, ...)

您可能希望尝试使用索引和引擎来获得最佳性能，但您可能只希望在关键字上使用一个索引。

【讨论】：