数据仓库索引

Question

我有一张有近六百万张唱片的桌子。标识唯一行的业务密钥相当大。自从我为一个新的多维数据集添加了这个新表之后，我们的更新处理现在花费了很长时间。我目前在更新的联接列上没有索引。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
*/

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

我们正在考虑提供一个散列解决方案，如下所示：

使用哈希字节跟踪和存储服务器数据的历史更改

短期而言，下周是一个重要的财政期末，系统需要表现良好，因此增加指数似乎是个好主意。所以我想尽快做我能做的事。您会推荐长期/新实现的散列解决方案吗？

Answer 1

我的假设是，所讨论的表是事实表，而不是具有巨大组合键的维度表：

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

至于事实表上聚集索引的列顺序，这取决于您如何访问它们。如果您只使用多维数据集来读取大量数据块，那么我可能会按时间顺序排列INSERT优先级，即将日期列放在第一位-这样，新行就会添加到索引的末尾(在最好的情况下)。

如果您在事实表上运行用户T查询，我将尽量按照索引查找或范围扫描的顺序排列索引列:首先，对单个维度键(例如“年份”、“类型”、“单元”或“部门”-type维度)进行过滤的列，然后对多维成员、范围或用于排序的列进行筛选。

当然，还有其他学校在如何建立指数方面--这不是一个“单一的正确答案”。

编辑:关于聚集索引和非聚集索引的更多信息：

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

聚集索引通常是“所有捕获索引”，它处理不适合现有非聚集索引的查询，这使得它更重要(在我看来)，它设计得很好，而不是仅仅在IDENTITY()列上。

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