Yar*_*lav 6 performance index sql-server-2008 query-performance
也许重复，但我相信我的情况有点不同。从我在 SQL Server Central 上得到的这篇文章的答案之一，它也很方便，但不是完全相同的场景：继承数据库时要做的 9 件事
几周前开始了一份新工作。我应该担任 BI 分析师和 SQL 开发人员。但就在第一次任务中，大家注意到一般来说一切都需要很长时间才能执行。问第一天指导我的人，我的主管你可以说，他告诉我他们知道数据库是一团糟。问我是否可以看一看可以做些什么，得到了肯定的回答。
所以我开始深入研究，使用几个非常方便的脚本，例如：
正如他们告诉我的那样，我发现一团糟。例如，blitzindex 过程返回近 2000 行，其中包含大量重复索引、NC 索引，包括表中的所有列、大量堆表、非常宽的索引等等。至于备份，几个星期以来一直没有完成，询问它，IT 人员只是每晚将数据库复制到不同的服务器。几个数据库超过 100Gb，其他几个也接近这个大小。每张桌子的统计数据每天都会更新。在不太大的表（只有几百万行）上，有些报告需要一个多小时才能完成。等等。
作为测试，我花了几天时间调整几个大表以及使用它们的不同过程和查询。使用分析器准备基线。然后做了一些更改并再次运行测试查询。正如预期的那样，一个现在需要大约 8 分钟的报告在大约 1 分钟内运行，而其他几个查询现在也只用了不到一半的时间。所有这些更改都是在测试服务器上完成的，我们还有一个报告服务器和一个生产服务器。
考虑到我应该是一名 BI 和 sql 开发人员，在办公室拥有有限的新权限，而不是 DBA。为了应对这种情况，您还建议我采取哪些其他措施？有一个指定的 DBA，但似乎只是一个做一些 dba 任务的 sql 开发人员。有 DBA，但他们告诉我他大约在半年前离开了。我应该忘记这些问题吗？或者作为一个大量使用数据库的人，我必须指出问题并提出解决方案？有人遇到过同样的情况吗？
编辑
谢谢大家的评论和回答。我发这个问题已经一个月了。所以现在我可以指出更准确的问题。
我相信索引是主要问题之一，但完全禁止删除索引，至少目前是这样。即使存在具有多个相同索引的关键情况，例如在其中一个主表上，大约有 3000 万行并且还在增长，也有 3 个 NC 索引，其中包含 7 个索引列并包括所有列。我可以在非常严格的监督下创建索引，但仅此而已。
有几个禁用的索引，它们会影响 CRUD 操作的性能吗？
“优步观点”综合症。在另一个视图中的另一个视图中有很多视图。关于这一点的一些建议？
许多 sp 在 SMSS 上执行得很快，但从 SSRS 调用时需要几分钟才能执行。阅读它发现似乎是一个与参数嗅探及其在存储过程中的使用相关的问题。一种建议是在 sp 上使用变量。我已经在其中几个尝试过这个，结果很成功。还有一些建议使用WITH RECOMPILE. 但据我所知，这可能会适得其反，因为每次都需要在重新编译时创建新的执行计划。与往常一样，我想这“取决于”，必须进行测试，看看它在哪些方面有帮助，哪些方面没有帮助。还有什么建议吗？
备份、日志等暂时不在我的掌握之中。所以我必须集中在性能和优化问题上。
第二次编辑
还有很多重复的 sp、udf 的表和一些其他对象。我猜是在某个模式的某个时间点创建的，通常是 dbo。但是，过了一会儿，创建了一个新模式来容纳一些对象，但 dbo 上的旧对象没有被删除。所以现在在修改东西时，我在数据库中遇到了很多重复的（有时是三次重复的）对象。
有没有一种简单的方法（可能是检查依赖关系？）来检查哪些对象仍在使用中，以便我可以报告应该删除哪些对象？
小智 3
当被问及我是否可以看一下并看看可以做什么时，得到的答案是“是”。
这是非常令人鼓舞的：您处于一个绝佳的位置来推进您的职业生涯并学习一些东西！
你提到的有些是问题，有些不是。我将简要回答他们，并提供一些更广泛的建议。
过程返回近 2000 行，其中有大量重复索引。如果它们真的是重复的——类型、顺序等等——那么多余的东西就可以被丢弃，而不会造成任何损失，也不必担心。DBMS 只能使用一个，并且它并不关心使用哪一个。 Insert每当索引消失时，性能就会提高。
NC 索引包括表中的所有列。普通的。这些被称为“覆盖索引”。它们类似于物化视图。
很多堆表。坏的。每张桌子都需要一把钥匙。有时你会被告知，“它没有钥匙”。如果为 true，则可以将整行定义为主键，除了添加额外的列（不在键中）作为计数。“添加”一行就相当于将计数加 1。
真正宽的索引可能有帮助，也可能没有帮助，参见。覆盖索引，如上所述。
数据库超过100Gb。正常情况下，数据库随着数据的增长而增长。
每张桌子的统计数据每天都会更新。好的。
有报道需要一个多小时才能完成。每个问题都是一个机会。
我的建议是通过阅读四本书来做好功课，并从一些戏剧性的小事情开始，修复运行时间最长的程序（或者你的老板认为是最大的错误）。
当您提出更改建议时，您希望能够在您所涉及的领域中自信且权威地发表讲话：关系理论和数据库设计以及 SQL Server。
对于理论，我按顺序推荐 CJ Date 的《数据库系统简介》、《SQL 和关系理论》以及《数据库设计和关系理论》 。当您被问及为什么应该以某种方式完成某些事情时，这将为您提供所需的信息和智力参考点。对于 SQL Server，我可以推荐Itzik Ben-Gan 的Inside Microsoft SQL Server 2008：T-SQL 查询。
不幸的是，阅读书籍是最容易的部分。困难的部分是将它们应用到数据库中。您可能会发现很难获取表中使用的所有查询的列表。不仅会让人很难知道需要哪些索引，而且意味着将一个表分成两个需要进行艰苦的测试以确保没有任何中断（并且应用程序也可能发生变化）。想要标准化数据库的人几乎没有朋友，因为任何更改，即使是正确且必要的更改，也可能会给其他人带来工作和干扰。
我会看看你的坏孩子，长期运行的报告或很多时候似乎是错误的报告。检查查询计划并根据 BCNF 考虑表。如果幸运的话，答案可能是添加索引，或者可能删除一些索引。如果不是，那么您就遇到了设计问题，这必然会涉及到其他人。
祝你好运。你的工作已经为你完成了。好消息是你有一个地方可以学习一些东西，并且可以更聪明地工作而不是更辛苦地工作。如果您坚持下去，有一天您将不会将查询时间减少 30% 或 50%，而是减少 99% 或更多。当这种情况发生时，您将在镜子中看到新的 DBA，所以要小心您的愿望。:-)
| 归档时间： |
|
| 查看次数： |
426 次 |
| 最近记录： |