问题描述
在 Azure 门户中，基于对运行时实际查询的分析，我获得了有关 sql 数据库的不错的性能提示。
我可以为我的数据库在本地运行吗？
解决方法
所以，虽然是的，这应该是一个评论，但它需要输入的字符多于我的空间（我认为）。话虽如此，我有一些值得讨论的事情，我认为你应该看看，如果你还没有。
首先，如果您的 SQL Server 版本允许它打开查询存储。我建议这样做的原因是，不仅一些开箱即用的功能种类为您提供了您正在寻找的东西，而且还允许您更深入地寻找自己的性能提升方案。
-
开箱即用的东西 - 查询存储中有专门帮助您查找回归查询、资源占用查询和其他您认为想要查找的有趣内容的部分。但是，前提是您在找到它们时已经知道如何处理它们。
-
深入挖掘 - 因为查询存储如何存储数据以及您可以为计划挖掘的 XML，所以您有大量选项可以找到诸如“表扫描”或“键查找”之类的糟糕内容。同样，自己进行这些查询并不容易，并且再次假设您在发现这些问题时已经知道如何解决它们。
-
该死的，您应该已经知道了 - 所有查询 stat dmv 和建议 dmv 的索引都可供您查看并了解事情的运行情况。还有其他 dmv 可以提供帮助，但我认为其中大部分都在实时表中，并且需要设置一个自定义进程来监视（为什么我坚持使用查询 sotre，因为它为您执行此操作）。同样，您猜对了，您仍然需要知道事后如何处理。不过，指数建议 dmv 应该持保留态度，因为您需要在充分了解和创建所有上述建议之前进行指数分析。
既然我们已经提到采取含糊其辞的建议 - 同样的思考过程应该应用于 Azure 建议，因为我之前看到过一些误报（最近的一件事是数据分类建议 - 对于 pk_NAMEOFCOLUMNTHATSASURROGATEID，真的吗？ )，所以我认为它永远不会出现。
还有大量廉价的软件可以做同样的事情——solarwinds DPA 曾经是坚如磐石的，但在他们最近的混乱之后，我不会责怪你甚至没有考虑那个。