SQL Server：最佳性能聚集索引和预期索引大小

Question

我正在为我在 SQL Server 2014 中的工作实施一个新协议（从 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

在日期和时间上使用聚集索引是否正确？

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

也就是说，我通常只对主键进行索引。当然，假设主键是身份或序列，而不是随机 GUID。

最频繁的查询将类似于

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

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

预计对所有列都有超快速查询

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

Answer 2

对于 1700 万/天，我们谈论的是每 5 毫秒一个条目（假设插入是均匀分布的）。如果要将日期和时间用作聚集索引，则需要确保在尝试插入数据时没有重复。这不是不可能实现的，但也不容易（尤其是在插入频率如此之高的情况下）。

您肯定希望使用 TIME(7) 作为数据类型，以便能够获得最细微的时间差来插入数据。

除此之外，将日期和时间列设为聚集索引听起来是个不错的计划。索引大小甚至比 Numeric(18,0) 小一个字节并且等于 bigint。

作为非聚集索引，我会使用 Product、Date、Time INCLUDE(something)。

您可能已经注意到我推荐的日期和时间数据类型。我强烈反对以字符格式存储数据。 原因 1：像 '20149999' 这样的字符串有效但不是有效日期，对于 '37:71:80:ab' 和 Time... 原因 2：如果您使用适当的数据格式，存储空间会更小，因此索引也会变得更窄。