我一直采用以下方法：首先以最少的索引集部署数据库，然后根据性能要求添加/更改索引。

这种方法行之有效。但是，它仍然没有告诉我在哪里可以提高性能。它只告诉我性能太差了，以至于用户抱怨它。

目前，我正在重构许多应用程序上的数据库对象。

因此，由于"过早的优化是万恶之源"，我是否应该不去寻求性能改进？

在重构应用程序代码时，开发人员一直在寻找提高代码质量的方法。有没有办法不断寻找数据库性能的改进？如果是这样，我们发现哪些工具和技术最有帮助？

我曾短暂地与"数据库引擎优化顾问"一起玩过，但没有发现它对我们有帮助。也许我只需要更多的经验来解释结果。

解决方案

分析查询，而不是显而易见的查询，而是分析访问不同表，视图等和/或者从不同表返回许多行的查询的复杂性

那会告诉你确切的方向

看来我们在谈论MS SQL。

启动事件探查器，并记录我们在数据库上运行的最常见查询。
然后在执行计划打开的情况下运行这些查询，我们将看到导致查询速度降低的因素(如果有的话)。然后，我们可以去优化查询或者在字段上添加更多索引。

SQL书籍将为我们提供概要分析和查询分析功能的良好概述。

概要分析是关键，但是在使用概要分析集时，必须确保它是准确的数据测试集，否则调整工具将无法为我们提供所需的准确结果。

另外，带有碎片的管理对象(2005年使用情况报告)也非常有帮助！

概要分析后，将我们认为麻烦的查询放入SQL Query Analyzer，并显示执行计划。标识正在执行昂贵表扫描的查询部分，并对这些表重新索引以最大程度地减少此开销。

试试这些参考：

优化SQL
如何优化查询

SQL Server执行计划！！！转到此处：http://dbalink.wordpress.com/2008/08/08/dissecting-sql-server-execution-plans-free-ebook/

我的方法是使用SQL Server Profiler将针对服务器或者数据库的命令收集到表中。有了这些信息后，就可以根据最大和平均执行时间，最大和平均cpu时间，以及(同样非常重要的)查询运行的次数进行查询。

由于我尝试将所有数据库访问代码放入存储过程中，因此很容易进行查询。如果使用内联SQL，可能会更困难，因为对查询中的值进行更改会使它看起来像是另一个查询。我们可以尝试使用LIKE运算符解决此问题，将相同类型的查询放入相同的存储桶中以计算聚合(最大值，平均值，计数)。

一旦有了潜在问题的"前十名"列表，我们就可以开始逐一查看它们，以查看是否可以对查询进行重做，使用索引可能会有所帮助，或者需要进行较小的体系结构更改。要得出前10名，请尝试以不同的方式查看数据：平均*计算期内的总费用，最严重的违法者的最高费用，仅是平均数等

最后，如有必要，请确保在不同的时间段内进行监视。在每个人都进入并运行其每日报告的早晨，与用户输入新数据的中午相比，数据库的使用情况可能有所不同。我们可能还决定，即使某个夜间过程比任何其他查询花费更长的时间，也没关系，因为它在下班时间运行。

祝你好运！

我们可能要检查当前索引的内部和外部框架，然后删除并重新创建它们或者重新组织它们。

确保使用生产量来分析行数和负载。在不同的负载/容量情况下，查询及其计划的行为不同

当然，我们必须分析查询并查看执行计划。但是，一遍又一遍出现的两个主要问题是，尽可能快地过滤掉，并尝试避免出现游标。

我看到了一个应用程序，其中有人将整个事件数据库表下载到客户端，然后根据某些条件对每一行进行一次筛选。通过将过滤器标准传递到数据库，并使查询在where子句中应用这些标准，性能得到了极大的提高。对于使用数据库的人来说，这是显而易见的，但是我已经看到类似的事情出现了。还有一些人的查询存储了一堆临时表，这些临时表充满了他们不需要的行，然后在临时表的最终联接中将其消除。基本上，如果我们从填充临时表的查询中删除，则其余查询的数据较少，并且整个查询的运行速度更快。

光标很明显。如果我们有一百万行并且逐行进行，那么它将永远花费。做一些测试，即使我们使用"慢"动态语言(如Perl)连接到数据库并在数据集上执行逐行操作，其速度仍然比数据库中的游标大得多。使用Java / C / C ++之类的工具执行此操作，速度差异甚至更大。如果我们可以在数据库代码中找到/消除游标，它将运行得更快...如果我们必须使用游标，则可以用任何编程语言重写该部分并将其从数据库中删除，这可能会极大地提高性能。

关于游标的更多说明，当心诸如SELECT @ col1 = col1，@ col2 = col2，@ col3 = col3之类的代码，其中id = @currentid在遍历ID的循环中，然后对每一列执行语句。基本上，这也是一个游标。不仅如此，而且使用真实的游标通常比这快得多，尤其是static和forward_only。如果我们可以将操作更改为基于设置的操作，则速度会更快.....也就是说，游标可以放置某些内容....但是从性能的角度来看，在基于设置的情况下使用它们会受到惩罚方法。

还要提防执行计划。有时，它估计花费数秒钟的操作非常昂贵，花费数分钟的操作非常便宜。查看执行计划时，请确保通过检查某些内容来进行检查，方法是在代码中插入一些"在此区域" SELECT，GETDATE()。

"过早的优化是万恶之源"

在数据库编程方面，我认为这句话是胡说八道。重新编写整个应用程序非常昂贵，因为开发人员不必在第一时间编写高效的代码。应该考虑所有t-sql代码如何影响数据库性能(当然，首先要考虑数据完整性)。性能应该胜过一切，除了数据完整性。

是的，有些优化问题是我们遇到问题之前不应该做的，但是某些事情应该理所当然地进行，以后不要修复。编写代码比编写代码效率更高的机会要花费更多的时间，而一旦我们了解了不良代码对效率的影响，编写代码的时间就不会更长。 Cervo对光标代码的讨论就是一个例子。基于集合的动作几乎总是比游标解决方案快得多，因此，当基于集合的解决方案可以使用游标时，绝不应该最初编写游标。与编写游标相比，编写基于集合的解决方案几乎总要花更少的时间，但获得该方法的唯一方法是永远不要编写游标。

并且没有理由使用select *代替指定字段名称。在MSSQL中，我们可以将这些名称从对象资源管理器中拖出，因此我们不能告诉我这样做太难了。但是通过仅指定我们实际需要的字段，可以节省网络资源，数据库服务器资源和Web服务器资源。那么，为什么程序员应该选择select *的惰性选项，而后再担心优化呢？

与索引相同。我们说我们只做最少的一组索引。取决于我们定义最小值的方式，这可能没问题，但是在所有外键上都具有索引至关重要，而我也不想将没有索引的数据库推入最常在哪里的几个字段中条款。如果用户是外部客户而不是内部客户，则他们不会抱怨网站运行缓慢，而是会转到其他地方。从一开始就计划有效的数据库访问仅具有商业意义。

我从一开始就没有考虑效率的主要担忧是，前两次情况太慢，公司往往只会在问题上投入更多设备，而不是提高性能。当人们开始进行性能调整时，我们已经拥有了数GB或者更多的数据库，其中有许多不满意的客户，他们得到的超时超过结果。此时，通常几乎必须重写数据库中的所有内容，与此同时，我们在失去客户。我记得在一家公司的商业应用程序中提供了支持，而客户服务代表试图帮助已经心烦意乱的客户使用电话时，实际上需要十分钟才能从一个屏幕切换到另一个屏幕。我们可以想象，由于我们无法更改的商业产品中设计不佳的数据库查询，该公司损失了多少客户。

通常，这里的提示：

http://www.sql-server-performance.com/

过去一直对我有用，对我有用。

我的建议是从适用于所有数据库的技术开始，然后尝试适用于MsSQL的技术。

优化SQL是困难的，没有硬性规定。我们可以遵循的通用指导很少，例如：

• 95％的性能改进将来自应用程序，而不是服务器或者数据库引擎配置。
• 首先进行正确性设计，然后对性能进行调整
• 减少到数据库的旅行
• 尝试以适合数据模型的方式表达事物
• 忽略有关性能的一般建议-是的，在某些时候，我们会发现系统或者SQL语句中其中一项规则不适用。

但是关键是我们应该始终应用80-20规则。这意味着在任何系统中，我们都需要调整代码的20％(通常要少得多)才能获得最大的性能提升。这是供应商提供的工具通常会失败的地方，因为他们通常无法猜测执行的应用程序/业务环境。

我的建议是，在这种情况下"过早的优化是万恶之源"绝对是胡说八道。

在我看来，所有关于设计的问题都需要在设计数据架构时考虑并发性，热点，索引，缩放和使用模式。

如果我们不知道需要什么索引以及如何不进行概要分析就立即配置它们，那么我们已经失败了。

有数百万种优化查询执行的方法，它们都是很好的，但最终，数据到达了我们告诉它的地方。