sql-server-2005 - 索引性能 BigInt 与 VarChar

Question

这是一个 数据仓库中的 FACT 表

它有一个复合索引如下

ALTER TABLE [dbo].[Fact_Data] 
ADD  CONSTRAINT [PK_Fact_Data] 
PRIMARY KEY CLUSTERED 
(
    [Column1_VarChar_10] ASC,
    [Column2_VarChar_10] ASC,
    [Column3_Int] ASC,
    [Column4_Int] ASC,
    [Column5_VarChar_10] ASC,
    [Column6_VarChar_10] ASC,
    [Column7_DateTime] ASC,
    [Column8_DateTime] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, 
SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, 
ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON
) ON [PRIMARY]
GO

在此结构中，所有 varchar 10 列都只有数字值。在查询和索引方面，更改这个 7800 万行结构以保存 BIGINT 而不是 VARCHAR 对我有好处吗？

我应该考虑的任何其他好处/缺点吗？

Answer 1

您应该绝对介绍代理人 INT IDENTITY()首要的关键!!
INT 已经为您提供了多达 20 亿行——这还不够吗？？

SQL Server 上的这个主键/聚集键的大小最多为 64 字节(而不是 4，对于 INT) - 这将使您的聚集索引和所有非聚集索引膨胀得无法识别。整个集群键(您的所有 8 列)将包含在该表上每个非集群索引的每一页中 - 肯定会浪费大量空间。

因此，在任何给定的索引表上，您将拥有多达 16 倍的具有代理 INT 聚集键的条目——这意味着 I/O 更少，读取索引页浪费的时间更少。

想象一下试图建立与该表的外键关系......任何子表都必须拥有所有 8列您的主键作为外键列，并在每个连接中指定所有 8 列 - 真是一场噩梦!

在 7800 万行时，即使只是将集群键更改为 INT IDENTITY 也可以为您每行节省多达 60 个字节 - 仅此一项就可以节省多达 4 GB 的磁盘空间(以及服务器中的 RAM 使用量)。这甚至还没有开始计算非聚集索引的节省......

当然，是的，我也会将 VARCHAR(10) 更改为 INT 或 BIGINT - 如果它是数字，则将字段类型设为数字 - 将其保留为 VARCHAR(10) 真的没有意义。但这本身并不会在速度或性能方面产生巨大差异 - 它只会使处理数据变得更加容易(例如，在比较值等时不必总是转换为数字类型)。

马克