每当我发现从我的数据库中检索数据的性能很慢时。我试图找出 SQL查询的哪个部分存在问题，我尝试对其进行优化，并在表中添加一些索引。但这并不能解决问题。
我的问题是：
还有其他技巧可以让SQL服务器性能更好吗？
可以使SQL服务器性能变差的另一个原因是什么？
答案 0 :(得分：22)
答案 1 :(得分：2)
当我与有这个问题的新开发人员交谈时，我通常会发现这是因为两个问题之一。如果您遵循这两条规则，它们都是固定的。
首先，不要检索任何不需要的数据。例如，如果您正在进行分页，则不要返回100行，然后计算哪些属于页面。让存储过程找出来并只检索你需要的10个。
其次，没有什么比你不做的工作更快。例如，我在一个系统中工作，在该系统中，每个请求的页面都检索到用户的完整角色和权限 - 对于某些用户来说，这是100行。即使只是在第一个请求中将其保存到会话状态，然后从那里使用它来进行后续请求，也会对数据库产生重大影响。
答案 2 :(得分：1)
建议你为你使用的数据库获得一本关于性能调优的好书（这是非常特定于数据库的）。这是一个非常复杂的主题，除了网络上的一般性外，无法真正回答。
例如，Dave Markle告诉您低效的查询可能会导致问题，并且有很多方法可以编写低效的查询以及更多方法来解决它们。
答案 3 :(得分：0)
如果您是数据库的新用户，并且可以访问数据库引擎优化顾问，则可以试探性地调整数据库。
您基本上捕获了在SQL事件探查器中针对您的数据库运行的SQL查询，然后将这些查询提供给DETA。 DETA有效地运行查询（不改变您的数据），然后确定您的数据库缺少哪些信息（视图，索引，分区，统计信息等）以更好地执行查询。
然后它可以为您应用它们并在将来监视它们。我并不是说DETA永远是对的，或者在没有理解的情况下做事，但我发现它绝对是一个很好的方式来查看你的查询在做什么，它们需要多长时间，以及如何索引数据库适当。
PS：总而言之，在项目开始时投资一名优秀的DBA要好得多，这样你就可以拥有良好的结构和索引。但那不是你现在所处的位置......答案 4 :(得分：0)
这是一个非常广泛的问题。而且已经有很多答案了。我仍然想补充一个重要因素 - Page Split。问题是 - 有很好的分裂和坏分裂。以下是解释如何使用transaction_log扩展事件来识别错误/讨厌的页面拆分的好文章
你提到了：
我尝试优化它并添加一些索引
但是，有时删除未使用的非聚集索引可能有助于提高性能，因为它有助于减少事务日志。阅读Top Reasons for Log Performance Problems
Wait statistics, or please tell me where it hurts提供了使用等待统计信息进行效果分析的想法。
要了解一些有关性能的新想法，请查看 Performance Considerations - sqlmag.com
- 将联接中的表分隔到不同的磁盘（对于并行磁盘I / O - 文件组）。
- 避免在具有少量唯一值的列上进行连接。
要了解JOIN，请阅读Advanced JOIN Techniques