ASP.NET/SQL 2008 性能问题

Question

我们开发了一个带有搜索屏幕的系统，看起来有点像这样:

_{(来源:nsourceservices.com)}

如您所见，有一些相当重要的搜索功能。您可以使用状态、 channel 、语言、事件类型的任意组合，然后还可以通过名称等缩小范围。

然后，一旦您完成搜索并且线索会在底部弹出，您就可以对标题进行排序。

查询使用 ROWNUM 执​​行分页方案，因此我们一次只返回大约 70 行。

问题

即使我们只返回 70 行，大量的 IO 和排序仍在进行。这当然是有道理的。

这总是会导致磁盘队列出现一些小峰值。当我们达到 300 万个线索时，它开始放慢速度，现在我们接近 5 个，磁盘队列有时会连续固定一两秒。

这实际上仍然可行，但该系统有另一个区域具有时间敏感过程，为简单起见，假设它是一个 Web 服务，需要非常快速地提供响应，否则会导致另一个区域超时结尾。磁盘队列峰值导致该部分停滞，从而导致下游超时。最终结果实际上是在我们基于 VoiceXML 的自动 IVR 中掉线，这对我们来说非常糟糕。

我们的尝试

我们已经尝试过:

• 将系统中的线索数量减少到最低限度的维护任务。
• 添加了明显的索引以提供帮助。
• 在探查器中运行索引调整向导并应用其大部分建议。其中之一要或多或少地在索引中重现整个表，所以我手动调整它以减少一点。
• 为服务器添加了更多 RAM。它有点低，但现在它总是有 8 gigs 空闲，SQL 服务器配置为使用不超过 8 gigs，但它从不使用超过 2 或 3。我觉得这很奇怪。为什么不把整个表放在 RAM 中？它只有 500 万条线索，而且空间很大。
• 倾注查询执行计划。我可以看到此时索引似乎主要在完成它们的工作——大约 90% 的工作发生在排序阶段。
• 考虑过将 Leads 表分区到不同的物理驱动器，但我们没有相应的资源，而且似乎没有必要这样做。

正在关闭...

我的一部分感觉服务器应该能够处理这个。鉴于该服务器的强大功能，500 万条记录并不算多，该服务器是具有 16 GB 内存的不错的四核服务器。但是，我可以看到排序部分是如何导致数百万行被触及而只返回少数行。

那么遇到这种情况你是怎么做的呢？我的直觉是我们或许应该削减一些功能，但如果有办法保持这一点完整，那将避免我与业务部门发生 war 。

提前致谢!

Answer 1

通常可以通过改进 SQL 查询来改善数据库瓶颈。在不知道它们是什么样子的情况下，考虑创建一个您按计划填充的操作数据存储或数据仓库。

有时，将复杂的关系数据库扁平化是可行的方法。它可以使查询运行得更快，并使优化查询变得容易得多，因为模型非常平坦。这也可能使您更容易确定是否需要扩展或缩小数据库服务器。容量和增长分析可能有助于做出这样的决定。

事务性/高度规范化的数据库通常不像 ODS 或数据仓库那样可扩展。

编辑:您的 ORM 可能也有它可能支持的优化，这可能值得研究，而不是仅仅研究如何优化它发送到您的数据库的查询。也许完全绕过报告的 ORM 可能是完全控制查询以获得更好性能的一种方法。