SQL Server : Optimal performance clustered indexing and expected indexsize

Question

我正在为 SQL Server 2014 中的工作实现一个新协议(protocol)(从 2010 年开始)，我需要为研究人员构建理想的数据库结构。

设置

• 1700 万行/天 ~ 2 GB 原始数据 ~ 520 GB/年
• 22 列
• 预计对所有列都有超快的查询

• 最常见的查询类似于以下内容

  select something, date, product 
  from mytable
  where product = '45' and date between '20100811' and '20140811' 
  

表格结构:

Date     | Product | Time          | something | something | something | something
----------------------------------------------------------------------------------    
20140811 | 45      | "14:55:46:13" |

我的表格在使用日期和时间时具有独特的组合。

问题

将日期放在单独的表中而不是放在一个巨大的表中会使查询受益吗？即在要求的日期执行连接操作。

在日期和时间上使用聚集索引是否正确？如果是这样，我应该如何使我的非集群化，以便达到最佳效果？

提前谢谢您!

Answer 1

Is it right to use clustered index on date and time?

这并不罕见，特别是如果您的绝大多数查询将按日期过滤并且您有大量临时查询。

也就是说，我通常只在主键上建立索引。当然，假设主键是标识或序列，而不是随机 GUID。

Most frequent query will be something along the lines of

对于该特定查询，您希望非聚集索引首先位于“产品”上，然后位于“日期”上。这将使您能够准确定位到正确的行(索引查找)。如果先执行“日期”，然后执行“产品”，则必须扫描日期范围内的所有记录(索引扫描)。索引的产品部分实际上不会产生影响，因为很少有记录具有相同的日期。

当有疑问时，将几十行数据写成一棵树。然后假装你是一台计算机并查找数据。如果您发现深入每个分支寻找可能的匹配项很乏味，那么您的数据库服务器也会如此。但是，如果您可以直接沿着树向下走到第一行，侧向走，拾取好的行，而不需要跳过坏的行，那么您就得到了一个好的索引。

Expected to have super-fast queries on all columns

这不会发生。聚集列存储可以为您提供对所有列的不错的查询(假设您没有做像 SELECT * 这样的愚蠢的事情)，但是为了“超快”，您需要覆盖索引。并且您无法为每个可能的查询创建覆盖索引。