2

我目前正在使用 MS SQL Server 2008，但我不确定它是否是完成这项特定任务的最佳系统。

我有一个像这样的表：

PK_ptA PK_ptB DateInserted LookupColA LookupColB ... LookupColF DataCol (ntext)

一个常见的查询是

SELECT TOP(1000000) DataCol FROM table 
WHERE LookupColA=x AND LookupColD=y AND LookupColE=z
ORDER BY DateInserted DESC

该表大约有 10 亿行，每天插入 500 万行。

我对 SQL Server 的主要问题是分片或分散数据文件不太容易。此外，导出似乎以每秒 1000 行（约 1MB/秒）的速度最大，这似乎非常慢。

我遇到的另一个问题是，对于 SQL Server，如果我想添加一个新的 LookupCol，日志文件会大幅增长，需要大量很少使用的可用空间。

这个问题有什么明显更好的解决方案吗？

4

2 回答 2

3

你有一个问题，它不是 SQL Server。让我也忽略你似乎有一个糟糕的桌子设计。

  • 传播数据文件实际上很容易。以后重组不是那么容易，但也是可行的。您的表格、文件组和文件布局如何？
  • 每秒导出 1mb 是个笑话。严重地。我已经在几分钟内处理了 1.5 亿行文件 - 每分钟运行超过 60.000 行。有什么东西吓坏了。临时空间？你做过性能分析吗？硬件外观如何？
  • 没有什么对日志使用有效。基本上像大多数专业数据库一样，日志包含事务期间所有更改的数据库页面。添加字段更改 - 所有页面。

你应该：

  • 重新设计数据库（如果您愿意，请使用视图将相同的旧表保留在适当的位置），使其不存在“LookupColA”等，而是标准化（LookupValue 和由“列”编码的 LookuPTable）。这样您就可以获得即时的附加字段。这变成了类似星型模式的数据仓库。
  • 进行性能分析。看起来你有一些问题。
  • 绝对告诉我们您的硬件；）

这里的这个问题绝对不是 SQL Server，它与糟糕的表设计和 - 可能 - 不足 - 硬件利用不当有关。

于 2010-03-24T12:09:18.550 回答
0

好的，表格设计（单独的答案）。Lokup 基本上是查找表。

所以....

  • 查找表
  • pk（整数）
  • 表格类型

  • 价值作为领域

  • 值表

  • PK

  • ValueLookupMap 表

  • ValueTable 条目的 pk
  • LookupTable 条目的 pk

因此，基本上，如果您添加一个查找“字段”，那么您只需在 LookupTable 中创建一组条目，然后在 ValueLookupMap 中添加条目。

于 2010-03-24T12:42:37.250 回答