Question

我们正在将现有的公司桌面应用程序迁移到云端。我一直在做很多数据库工作，我一直在为适当的索引优化它们，以便根据需要保持响应能力。

我试图优化几个表并且无法让索引在我想要的所有调用上运行，所以在临时表上尝试了一个非唯一的集群键，看看它是否会给我更好的数字'他们将拥有磁盘位置，因此它应该能够通过顺序读取而不是重复的随机读取来找到它们。

我有2个关注表，肯定会占据大部分流量，但问题是一样的。我们希望在用户设置表中有数百万到数千万条记录。我们确认的遗留软件将每个用户的1300-1500个配置选项同步到数据库中。预计表格大小至少约为4千万至5千万行。

我最初设计的表是

    CREATE TABLE dbo.Settings
    (
       SettingID BIGINT PRIMARY KEY NOT NULL IDENTITY(1,1),
       CustomerID INT NOT NULL,
       SettingTypeID INT NOT NULL
       .... other rows
    )

CREATE NONCLUSTERED INDEX [INDEX_NAME] ON dbo.Settings(CustomerID);

我认为更好的优化是

CREATE TABLE dbo.Settings
(
   CustomerID INT NOT NULL,
   SettingTypeID INT NOT NULL,
   .... other rows
)

CREATE CLUSTERED INDEX [INDEX_NAME] ON dbo.TRSettings(CustomerID);

产品的所有查询都是表单形式，可能还有某种附加条件，例如我想要给定页面的特定设置。

SELECT * FROM dbo.Settings WHERE CustomerID=@CustomerID ...

从分析中，选择似乎要快5-50倍，平均快25-30倍。因为它可以进行范围扫描而不是非聚集索引的重复查找。

由于某些原因，在我的一些测试中，插入读取速度提高了50％（我的猜测是它必须重建非聚集索引并写入实际表格）。

带来了我们的产品主导，目前的共识似乎是'如果需要，我们将投入更多的硬件'，因为我们不得不花费大约半天的时间重写一些代码才能工作（相当积极的新表格不会不使用实体框架或者你可以访问uniquifier隐藏列吗？），但据我所知，有什么问题我不知道？对于客户记录来说，您通常会将多个项目（即用户设置）编入索引，最好有一个像这样的索引来近似NoSQL集群，这样您就可以保证磁盘位置。我对插入性能不太熟悉，看看树重建是否会出现意外问题。

SQL Server - 非唯一的聚簇索引优化

0 个答案: