什么时候才能真正专注于表演？

Question

我们刚刚完成了数据库驱动的web应用程序的第一个版本，现在正在进行回归测试。该应用程序具有具有许多不同筛选条件的高级搜索。当第一次使用搜索时，只需3( 28)个最低要求的搜索条件，就需要15-20秒来计算和检索页面加载的数据。

这只在第一次运行搜索(使用存储的proc)时才会发生。之后的搜索需要2-6秒。

存储过程的复杂度约为1500至2000行。我想让它第一次运行到6秒，然后像1-2秒，但我似乎找不到时间让它更快。

我的问题是，如果只在第一次运行搜索时速度较慢，这是否为用户所接受？有没有其他人在创建高级搜索方面有过类似的经验？你的解决方案是什么？

Answer 1

“它是否可以接受”不是一个技术问题，而是一个产品问题。在某些产品中，2-6秒可能被认为是极其缓慢的，而在另一些产品中，15-20秒可能相当缓慢。竞争产品的速度有多快？类似的产品有多快？有多少百分比的客户会看到较长的原始查询和更快的缓存查询？如果您期望获得1,000万次查询，那么一个缓慢的查询将是微不足道的。如果你期望十个，那就没那么多了。这些问题的答案会告诉你是否需要优化。

您可能尝试的一个技术解决方案是预先准备这些查询。我不清楚到底有多少查询可能存在，但如果这些“缓慢”查询的数量足够少，那么在部署之后立即运行它们，这样就不会有实际的客户看到它们。如果有大量可能的查询，那么您可能会运行那些最常见的查询。

Answer 2

你可以做几件事：

为性能创建视图。视图是一种意向契约，它告诉RDBMS“我将经常运行此查询”。当您这样做时，RDBMS优化了对此数据的访问。

为简单性和调优创建视图。创建视图是为了将大解决方案拆分为更小的解决方案。通过这种方式，您可以准确地测量瓶颈所在，并试图改进有问题的领域。

创建非规范化表(物化视图)。有时，为了使某些报告更快，特别是对于非事务性的数据，创建摘要表是值得的。

为查询创建一个非事务性数据库或数据仓库。在数据库不是事务性的情况下，大多数RDBMS都有对查询的特殊数据库进行调优的方法，也就是说，它不会被插入或更新连续地命中。当数据库有此用途时，整组调优配置(如果不同的话)。它比通用数据库更高效。

将大多数查询表放入速度更快的磁盘中。将表空间中的大多数查询表移动到更好、更快的磁盘和更好的连接(SAN)中。将不那么重要的表移动到更慢、更便宜的磁盘上，也不要移动这么快的连接。

使用结构化编程技术将存储过程拆分为较小的存储过程，这样就可以避免复杂性。这样，你就可以更好地集中精力提高你的表现，一旦你的脸上没有所有的复杂性。

使用绑定变量的查询，避免连接查询。这样，RDBMS就能够在查询区域中兑现它们，并且它们运行得更快，因为您可以节省解析时间和计划时间。

记住，DBA是您的朋友，他/她可以做很多事情来提高数据库性能。不要仅仅依靠你的编程技巧。你不是一个人。