数据仓库索引

Question

我有一张有近 600 万条记录的表。标识唯一行的业务键非常大。自从我为新多维数据集添加了这个新表以来，我们的更新处理现在需要更长的时间。我目前在更新的连接列上没有索引。SQL Server 估计执行计划说我应该在业务键上创建这个索引：

/*
Missing Index Details from Server.db
The Query Processor estimates that implementing the following index
could improve the query cost by 86.9178%.
*/

/*
USE [db]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [schema].[Production] 
(
    [ProdId],[PriceCalc],[CalcTypeId],[OprId],[CostGroupId],[Resource],
    [BOM],[ResourceDepartment],[OprNum],[DateWIP],[DataAreaId],[Partition]
)
INCLUDE 
(
    [ProdOrderStatus],[ManufacturedItemId],[CalcType],[CalculationLevel],
    [CostAnalysisOrderType],[CostGrouping],[UnitId],[WorkCenter],[Name],
    [RealisedConsumption],[RealisedCostAmount],[RealisedCostAdjustment],
    [EstimatedConsumption],[EstimatedCostAmount],[LotSizeVariance],
    [StandardQty],[StandardCost],[ItemStandardQty],[HasSubstitutionVariance],
    [R2],[R3],[StandardQtyByRAFQty],[StandardCostByRAFQty],[ProductionOrderType],
    [RealisedAllocation],[CostVariance],[QuantityVariance],[SubstitutionVariance],
    [TotalVariance],[ComponentItemId],[InventoryUOM],[InventConsumptionTransUOM],
    [BomConsumptionTranUOM],[TransactionUOM],[TransUOMToInvUOMConversionRate],
    [InventConsumptionInvUOM],[BomConsumptionInvUOM],[TotalNetWeightPerUnitInvUOM],
    [InventoryNetWeightUOM],[ReportingNetWeightUOM],
    [NetWeight_InvUOMToReportingUOMConversionRate],
    [InventConsumptionTotalNetWeightInvUOM],[BomConsumptionTotalNetWeightInvUOM],
    [InventConsumptionTotalNetWeightReportingUOM],
    [BomConsumptionTotalNetWeightReportingUOM],
    [FinancialProductId],[FinancialDepartmentId],[FinancialMarketId],[FinancialCodeId],
    [FinancialTypeId],[FinancialSiteId],[ProdPoolId],[Company_SK],[ComponentItem_SK],
    [EndedDate_SK],[DateWIP_SK],[FinancialCode_SK],[FinancialDepartment_SK],
    [FinancialMarket_SK],[FinancialProduct_SK],[FinancialSite_SK],[FinancialType_SK],
    [InventoryNetWeightUOM_SK],[InventoryUOM_SK],[ManufacturedItem_SK],
    [ProductionOrder_SK],
    [ReportingNetWeightUOM_SK],[TransactionUOM_SK],[BatchRunId],[ValidInd],[ScrapVar],
    [QuantityPO],[ExpectedConsumption],[FibreScrapFactor],[QtyAndSubVariance],
    [EndedDate],[RealisedAllocationCost],[FilmScrapFactor])
GO
*/

它想在键列上创建一个索引，但是它想包含许多列。我应该听它还是只包含关键列？谢谢你的帮助。这是一个生产问题，所以我不能去测试不同的东西等。

我们正在考虑采用散列解决方案，如下所示：

使用 Hashbytes 跟踪和存储 SQL Server 数据的历史更改

短期来看，下周是重要的财务收尾期，系统需要表现良好，所以加个指数似乎是个好主意。所以我想尽快做任何我能做的事情。您会为长期/新实现推荐散列解决方案吗？

Answer 1

我正在假设有问题的表是一个事实表，而不是具有巨大复合键的维度表：

只是为了在短期内解决性能问题，我会将所有这些键列添加为表的聚集索引，这意味着您不必INCLUDE像建议的索引那样进行大量度量和内容。此外，如果数据允许，请使索引唯一。

至于事实表上聚集索引的列顺序，这取决于您访问它们的方式。如果您只使用多维数据集来读取大量数据，我可能会INSERT通过按时间顺序排列索引来确定优先级，即将日期列放在首位 - 这样，新行会添加到索引的末尾（最好的世界）。

如果您在事实表上运行用户 T-SQL 查询，我会尝试按顺序排列索引列，以便尽可能多地提供索引查找或范围扫描：首先，按单维键过滤的列（想想“年份”、“类型”、“单位”或“部门”类型的维度），然后是根据多个维度成员、范围过滤或用于排序的列。

当然，还有其他学校关于如何建立索引——这不是一个“唯一正确的答案”。

编辑：更多关于聚集与非聚集索引：

我猜您已经有一个现有的聚集索引，这就是 SQL Server 建议使用非聚集索引的原因。但是，必须使用INCLUDE列显式定义非聚集索引。聚集索引定义了表的实际存储/排序顺序，因此，它们将隐式包含表中的所有列（我不会进入像 varchar(max) 和 xml 之类的 LOB 列）。

聚集索引通常是“包罗万象的索引”，它负责处理不适合现有非聚集索引的查询，这使得它更重要（在我看来）它是精心设计的，而不是例如，就在一IDENTITY()列上。

另外，非聚集索引将占用更多的驱动器空间，因此覆盖表所有列的非聚集索引实际上将占用与表本身一样多的空间。聚集索引是表。