ASP.NET/SQL 2008 性能问题

Question

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

_{（来源：nsourceservices.com）}

如您所见，有一些相当重要的搜索功能。您可以使用状态、渠道、语言、活动类型的任意组合，然后按名称等缩小范围。

然后，一旦您搜索并在底部弹出潜在客户，您就可以对标题进行排序。

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

问题

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

这总是会导致磁盘队列出现一些小峰值。当我们达到 300 万个潜在客户时，它开始变得更加缓慢，而现在我们已经接近 5 个，磁盘队列有时会持续一两秒。

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

我们的尝试

我们已经尝试过：

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

即将结束...

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

那么在这种情况下你做了什么？我的直觉是我们也许应该削减一些功能，但如果有办法保持这一点完好无损，那将避免我与业务部门的战争。

提前致谢！

Answer 1

1. 确定最有可能运行哪些即席查询或使用存储过程限制搜索条件。您可以汇总数据吗？处理一下这个
   像数据仓库一样的应用程序。
2. 为搜索中涉及的每个列创建索引以避免表扫描。
3. 在表达式上创建片段。
4. 随着更多潜在客户的加载，定期重新组织数据并更新统计信息。
5. 将查询（结果集）创建的临时文件放入 ramdisk。
6. 考虑迁移到 Informix OnLine 等高性能 RDBMS 引擎。
7. 在查询时启动另一个线程以开始显示结果集中的 N 行
   继续执行。

Answer 2

考虑您的 ORM 如何创建查询。 如果您的搜索性能很差，也许您可​​以尝试使用存储过程来返回您的结果，如有必要，还可以尝试使用专门针对正在使用的搜索条件定制的多个存储过程。

Answer 3

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

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

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

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