2011-02-09 48 views
2

嗨,大家好我有一个sql server 2008数据库以及30000000000记录在其主表中。现在我们正在为我们的查询寻找性能。我们已经完成了所有的索引。我发现我们可以将我们的数据库表分成多个分区,这样数据将分散在多个文件中,并且会提高查询的性能。 但不幸的是,这个功能只适用于sql server企业版。这使我们感到不舒服。如何处理sql server中数十亿的数据?

你们可以建议任何其他方式来维护和查询性能。

eg. select * from mymajortable where date between '2000/10/10' and '2010/10/10' 

此查询大约需要15分钟检索大约10000条记录。

+5

您需要`date`上的索引 – 2011-02-09 09:05:51

+0

可能是http://stackoverflow.com/questions/2794736/best-data-store-for-billions-of-rows的副本 – Thunder 2011-02-09 09:07:15

回答

3

SELECT *显然会比使用覆盖索引的查询效率低。

第一步:检查查询计划,寻找和表扫描,并采取最省力(%)

如果你还没有在你的“日期”列的索引,你肯定需要执行的步骤一个(假设有足够的选择性)。尝试减少选择列表中的列,如果'足够'少,将这些索引添加到索引included columns(这可以消除对聚集索引的书签查找并提高性能)。

你可以打破你的数据成单独的表(比如按日期范围),并通过视图结合起来。

它也非常依赖于你的硬件(#内核,内存,I/O子系统的速度,网络带宽)

建议你发布你的表和索引定义。

1

首先总是避免Select *因为这将导致选择获取所有列,如果只需要你获取了很多不必要的数据列的索引。仅使用需要检索的确切列可以让服务器更好地使用索引。

其次,有你的索引上包括列一看,这种方式往往请求的数据可以被包含在索引中,以避免读取行。

第三,您可能会尝试使用int列作为日期并将日期转换为int。在范围搜索中,Ints通常比日期更有效,特别是如果您有时间信息,并且您可以跳过索引将更小的时间信息。

一两件事来检查是服务器使用的执行计划,您可以在Management Studio中看到这一点,如果你能够在菜单中显示的执行计划。它可以指出问题出在哪里,你可以看到它尝试使用哪些索引,有时它会建议添加新的索引。

也可能表明其他问题,表扫描或索引扫描是坏的,因为它表明,它在整个表或索引扫描,而索引查找好。

这是理解服务器如何工作的好资源。

0

如果添加上日期的指标,你可能会查询加快由于索引查找+键查找,而不是一个聚集索引扫描,但如果你在日期过滤器将返回过多的记录索引将不会帮助你根本就是因为索引查找的每个结果都执行了密钥查找。SQL服务器将切换到聚簇索引扫描。

为了获得最佳性能,您需要创建一个覆盖索引,即在索引的“包含列”部分包含所需的所有列,但如果您使用select *

select *方法的另一个问题是您无法高效地使用缓存或执行计划。如果您确实需要所有列,请确保指定了所有列而不是*。

你也应该充分quallify对象名称,以确保你的计划是可重复使用的

0

则可以考虑创建一个归档数据库,并经过动什么,比方说,10 - 20年到归档数据库。这应该大大加快您的主要生产数据库,但保留所有历史数据以满足报告需求。

0

我们在讨论什么类型的查询?

这是生产表吗?如果是的话,看看更多的规范化,看看你是否不能进一步尽量规范化数据库。

如果这是报告,包括大量的专用报告查询,这尖叫数据仓库。

我会创建一个带有单独预处理报告的数据仓库,其中包含您可能期望的所有计算和聚合。

我有点担心商业模式,它涉及到处理BIG数据,但没有产生足够的收入,甚至没有吸引足够的风险投资来升级到企业。

相关问题