聚集索引 - 权衡查询与插入？

Question

我正在努力提高我的应用程序的数据库性能，现在涉及到聚集索引的部分。我没有这方面的经验，所以我想问一下。

我的申请注意事项

在我的应用程序中，我有 Show 的概念。

这意味着用户可以创建/打开一个节目，然后它将只访问与该节目相关的对象（演员、衣服、物品等）。 因此，使用 "...WHERE ShowId = X"

进行查询真的很常见

此外，由于集成，我们确实有相当多的插入（我们每天都在运行一项工作，它会在数据库中获得 +/- 30k 的新行，所有这些都在同一个 Show 中）并且删除并不常见......用户可能会删除一个节目（这确实需要很长时间）。

应用程序的用法通常是这样的：

• 用户根据“主秀”（复制大量数据仅更改 ShowId）创建节目
• 用户在某些屏幕上导航以检查此数据
• 用户调用一种算法来处理该节目的输入并生成大量输出（在同一节目中再次插入 30k+ 次）
• 用户分析这些输出

问题

基于此，我认为最好的聚集键将在每个表的 [ ShowId, id ] 上。但是然后，阅读this 文档，我怀疑考虑到插入的数量，这是否不会使情况变得更糟，或者是否因为插入是在同一个 ShowId 上进行的，所以可以。

我无权访问 PRD 数据库，也无权访问它的副本进行测试。我使用 dev 数据库进行了测试，但它太小了，似乎根本没有任何影响。

有人可以帮忙吗？

Answer 1

如果没有更多信息，很难给您答案。您也应该考虑发布表格结构。

确实，对于您添加的每个索引，您都会在插入时产生开销。但是，如果您需要使用“WHERE SHOWID=...”，那么在这种情况下，您的 SELECT 将对您的 SELECT 产生强烈的积极影响（在一张大表上，并且考虑到 SHOWID 非常有选择性，即在很多记录上的几条记录）整张桌子）。

你说：

“我无权访问 PRD 数据库，也无权访问它的副本 测试。我用开发数据库进行了测试，但它太小了，没有 似乎没有任何影响。”

但是您可以使用执行计划来查看查询将如何使用您的索引/表。此外，您可以很容易地生成多个随机记录来进行测试。