堆有性能问题的大表

Posted 2023-05-08

【中文标题】堆有性能问题的大表

【英文标题】：Heap big table with performance issues

【发布时间】：2017-11-03 18:06:24

【问题描述】：

我有一个业务案例，我需要存储有关车辆车间发票的所有详细信息（发票编号、经销商、车辆编号、和平、服务性质……）。我有超过 50 列都在同一个查询中被选中。

在我的治疗中，我需要做一些特定的治疗，以获得净化的数据和一些基本的转换。我面临的问题是我没有能够创建主键的业务密钥，因为我的车间数据的每一行都代表发票详细信息（如一件赔偿），有时我有相同的重复行，因为那里在车间里不止一次进行相同的操作。

所以我发现自己有一个没有任何聚集索引的堆表。所以我尝试创建一些非聚集索引来提高性能，但它并没有真正起作用，每次我加载更多数据时，选择查询都会比以前花费更多的时间。

我检查了执行计划，发现问题的主要原因是 RID 查找（堆），它的成本超过 85%

我需要一些帮助 ^^ 并且我已经有了创建一个定义发票的复合索引的想法，但它在我的数据集中不会是唯一的？你怎么看？

【问题讨论】：

常规的 b-tree 索引应该没问题。你应该用一个慢查询的例子和你当前的索引结构来问另一个问题。

谢谢，这是一个堆，没有多少查询我只运行一个查询来选择当天加载的所有数据并处理它。所以目前我有非聚集索引，希望改进选择查询，但它没有多大帮助

【参考方案1】：

聚集索引不需要是唯一的（如果不是，SQL 会添加一个内部的“唯一标识符”，以便可以区分行），所以继续创建一个！

【讨论】：

感谢您的回复。您认为使用聚集索引会在加载数据时产生任何第二种影响吗？我每天需要加载 100 万行。

它可能比插入到堆中稍微慢一些，但并不令人担忧。影响插入性能的变量太多，您需要自己测试才能确定。另一种方法是在插入之前删除聚集索引并在之后重新创建，您需要再次测试它的速度和任何可用性要求。

@HadriaMehdi，聚集索引键的最佳选择很大程度上取决于您的查询。由于一张表只能有一个聚集索引，因此可能需要权衡取舍。

谢谢，我会试试我的聚集索引，看看它给出了什么:)。 @Dan Guzman，事实上我只有一个查询要运行。它从最初加载数据的巨大表中选择最近的数据，然后将其加载到临时表中进行处理，然后再加载到最终表中。

@HadriaMehdi 请注意您删除有关您正在运行的实际查询的黄金信息需要多长时间。这与您创建的索引有 100% 的关系。它确实应该在原始问题中提供更多详细信息。