可能有些人甚至不知道这些功能，所以你会从这篇文章中学到很多东西，这实际上可以帮助我更好地进行优化，你们中的一些人可能每天都会使用它们，这样你就可以帮助我和其他人少DBA证明用户。
我正在使用SQL-Server 2005 Standard
我经常运行SQL Server Profile r。每次我发现临时查询或sps的执行时间超过我对复杂查询可能的限制在100ms以下，而对于短复数查询则超过30ms（数字并不意味着什么，只是为了说明一点）。在我找到可能有问题的查询后，我将它们写下来，这样我就可以使用Database Engine Tuning Advisor对表执行重载查询，结果给出了我需要构建的索引以提高性能。每晚我都会从维护计划中执行索引重建功能。
现在提问时间!!!
1.如果数据库引擎优化顾问为我创建10个索引，而改进百分比约为40％，我是否应该使用它的建议？更好的问题是我应该遵循的指数/改进百分比的比率是多少。索引占用空间和时间来重建。
2.如果我为每个有问题的查询创建大约5-7个索引，我最终可以为每个DB提供500个索引。我可以构建多少个索引，以便DB正常运行？有什么限制吗？
3.除了使用我的方法或用你的手和眼睛去sp之外，还有其他方法可以优化（或重新设计）你的数据库吗？
答案 0 :(得分：1)
您可以让SQL事件探查器登录到表，因此它会将查询写入您指定的表。如果可以的话，让它运行几个小时 - 或者尽可能多地覆盖尽可能多的查询/事件。
接下来，使用数据库引擎优化顾问 - 并使其使用此查询表作为其源输入。您会发现它会查看整个模式，并建议您创建一些索引，并删除其他索引。
这比单独查看查询更好，尽管它仍然有它的位置。
答案 1 :(得分：1)
这个问题没有正确答案，因为它在很大程度上取决于您的工作量。
对于读取比例较高的工作负载（例如数据仓库），创建一个索引可能是有意义的，这对于创建具有更多写入量的环境会产生积极的反效果。
DTA可以通过评估对整体工作负载的影响来帮助解决这个问题，但您需要尝试捕获代表性样本（而不仅仅是表现不佳的查询）。 SQL事件探查器是非常耗费资源的，因此为了尽可能减少对服务器的影响，您需要使用带有适当过滤器的服务器端SQL跟踪来仅记录与感兴趣的数据库相关的事件。
单独识别性能最差的查询如果安装了至少SQL2005 SP1客户端工具，则应该能够右键单击Management Studio中的数据库节点并使用Reports - ＆gt; “标准报告”菜单，用于查看具有最高CPU / IO的缓存中的计划。
如果您对这个领域感兴趣，我推荐书SQL Server 2008 Query Performance Tuning Distilled（大部分也适用于SQL2005）