Question

我找到了一张如下表：

 CREATE TABLE [dbo].Table1 (  
  id INT primary key IDENTITY (1, 1),  
  [idUser] INT  NOT NULL ,  
  [Amount] INT NOT NULL ,  
  [Attempts] INT NOT NULL ,  
  [date] [datetime] NOT NULL ,  
  [SUM_Amount] INT NOT NULL   
 ) ON [PRIMARY]

此表格由作业创建并填充特定时期的汇总数据。

特殊性：

此表最多可容纳一百万行
idUser是唯一的
sum_Amount正在运行前一行金额的总计。

此表将按原样保存，不进行更新或删除或插入操作。只是这种类型的查询：

 select top (@n) * from table1
 order by [SUM_Amount] desc, [Attempts] desc

 select top (@n) * from table1
 where [SUM_Amount] >=@m order by [SUM_Amount] asc

我认为它会提高改变为聚集索引的性能，如下所示：

 CREATE TABLE [dbo].Table2 (  
  id INT IDENTITY (1, 1),  
  [idUser] INT  NOT NULL ,  
  [Amount] INT NOT NULL ,  
  [Attempts] INT NOT NULL ,  
  [date] [datetime] NOT NULL ,  
  [SUM_Amount] INT NOT NULL  

 CONSTRAINT [PK_Nueva]
   PRIMARY KEY CLUSTERED ([SUM_Amount] desc, [Attempts] desc, id asc)   

 ) ON [PRIMARY]

我读到使用no unique clustered index会添加一个4字节的隐藏标识符列（http://msdn.microsoft.com/en-us/library/ms190639(v=sql.90).aspx），所以我决定将Identity（id）添加到集群索引（不确定它是否是正确的方法）

我想问（冒险听起来很荒谬，但需要确定）：

怎么可以改进？
我会对磁盘大小产生影响吗？
我是否应该在插入所有数据后重建索引？

修改

关于id，我认为这是一个坏习惯。我保留了它，不知道以前的工作如何计算总计（我没有访问权限）

有很多像这样的表，每天都有数百个（不要问我为什么）。这就是为什么DBA团队要求我不要因为大小问题而创建新索引。这就是我想通过聚集索引重新排列表结构的原因。还会更改超出正常范围的数据类型。

Answer 1

好的，所以一百万行非常小，根据所提供的信息，你的表格大小不会超过75-100 MB，因此我不知道你为什么提到这些，我假设他们是相当微不足道的。除此之外，您不希望索引表并包含ID（PK），因为您将获得RID查找。基本上你的PK中的id对你没有任何作用（你说数据是固定的，不变的，没有理由继续检查任何东西的唯一性......这是在源系统中完成的）如果有什么会减慢你的查询所以我要做的只是在SUM_Amount上添加一个聚簇索引，它将为你要去的数据排序，并在显示的两个查询中创建索引搜索。

针对特定查询的聚簇索引改进

1 个答案: