问题
作为SQL Server Professional，应用程序性能是我的首要任务之一。我知道我们的应用程序效率低下，并且我们一直在不断努力以保持内部和外部用户的生产力。我们的团队整日收集数据并获得大量指标，这非常好，但是要找出能够带来最高性能提升的问题确实很困难。通常，我们会从主意上向后射击。我需要知道，花时间在我们的代码发布过程中将产生可观的性能提升。我该如何纠正应用程序中的效率低下并使我们的SQL Server DBA团队将精力集中在最重要的问题上？
解
由于在服务器，数据库和对象级别具有大量性能指标，因此每天要处理的项目数量越来越多，因此很难关联，聚合和趋势化数据。进一步采取此步骤并真正确定SQL Server性能问题的优先级通常变得非常困难。通常，引起最多关注的性能问题通常是基于响亮的抱怨。这不一定是最大的问题。这可能是另一个问题的征兆。
在SolarWinds，数十年来，他们一直在通过查找和分析SQL Server性能问题来帮助全球的公司。借助最新版本的 数据库性能分析器（DPA），SolarWinds的团队通过分析总体工作负载来帮助数据库管理员优化工作负载，从而使这一步骤更进一步。该优化基于每天分析总体工作负载，以确定查询和表级别的最大问题，然后提供切实可行的建议，并提供估计的性能优势以证明更改的合理性。让我们深入了解查询性能分析和表优化顾问，以了解如何简化数据库性能优化。
SolarWinds数据库性能分析器中的查询性能分析
查询性能分析提供了一种方法，可通过着重于等待时间最长的查询，钻取查询中最有问题的部分并获得建议以改进查询（包括代码）来简化查询性能。这会将最重要的信息以一种智能的方式尽快地放在DBA的前面，以解决性能问题，例如：
- 总体工作量最昂贵的查询
- 每个查询的最高等待类型
- 查询计划效率低下的步骤
- 关联堆栈中多个层的性能指标
- 每天执行代码以确定对等待类型的影响
登录到DPA并签出30天趋势页面时，此过程开始，您可以在其中钻取有关相关代码，其指标和建议的单个查询。
当您从30天趋势视图中单击查询哈希时，将显示过去30天该查询的所有性能指标-保持时间框架一致。新的查询性能分析视图包含可折叠/可扩展的多个部分，因此可以将重点放在最重要的数据上。该视图中的数据可以通过两种方式智能显示：
- 如果有资源指标与主要等待查询相关联，则这些资源指标将被拉到指标部分。
- 如果此查询涉及重大阻止（作为阻止者或被阻止者），它将扩展阻止部分。
- 如果优化器在您设置的时间范围内对该查询使用了多个计划，它将扩展“计划”部分。
前两个部分保留用于此查询分析期间的任何发现：
- 查询顾问–缺少索引建议，重要的等待类型，异常的使用模式（具有高执行率的时段），缺少where子句，全表扫描等。
- 表优化顾问–指示此查询导致针对一个或多个表的低效率工作负载（稍后会对此进行更多介绍）。
如果查询本身没有发生变化，但是却产生了更多等待时间，那么此视图中提供的其他部分之一可以帮助回答原因，例如：
- 执行量或物理读取量与逻辑（统计量）相比增加
- 计划变更（计划）
- 系统资源压力（指标）
- 并发（阻塞）
下面的示例显示所选查询的主要活动是“内存/ CPU”。因此，内存和CPU指标被引入到“指标”部分的视图中。但是，如果主要的等待与磁盘相关（例如pageiolatch_ex），则磁盘延迟和其他相关指标将被拉入视图。
当我们点击屏幕右侧的计划链接时，我们可以在页面底部看到整个查询计划以及相关的费用以及计划建议。计划建议还包括相关影响，以证明遵循建议的好处。
要继续进行查询分析，您可以在图表级别选择基于特定报告添加相关计数器的选项。顶部图表也很粘滞，徘徊在每个部分的上方，以更好地关联30天趋势图表中的数据。
除了可以为特定图表添加统计信息之外，您还可以添加66个单独的指标，以根据工作量真正自定义图表。
此外，在查询级别的性能指标和相关建议，使用“查询性能分析”，您还可以单击“ SQL文本”选项卡以查看与查询关联的T-SQL代码以及“支持数据”选项卡查看与查询计划相对应的数据库，用户，文件，计算机，程序等。
查询性能分析器如何为我提供帮助？
查询性能分析器通过以下方式帮助SQL Server专业人员：
- 智能显示最重要的性能信息，以简化DBA的性能调整过程
- 能够自定义界面以查看与您的工作负载最相关的指标
- 查看查询性能的30天趋势，并能够深入查询计划详细信息
- 复制，粘贴和最少更新代码以快速跟踪性能改进
- 合理的性能建议：
- 查询效率低下
- 索引调整
- 缺少索引
- 谓词问题
- 数据类型不匹配
- 过时的统计
- 通过可自定义的视觉效果提供查询性能的整体视图
SolarWinds数据库性能分析器中的表优化顾问
根据DPA已收集的数据，最新版本中的第二个新功能称为 Table Tuning Advisor。这些建议是DPA已经收集的大量数据的副产品。但是，现在每天都在分析等待类型，以了解表级别的性能影响以及特定建议如何同时使环境中的许多流程受益。通过在对象级别聚合的专有算法，无需在监视的SQL Server实例上增加额外负载即可了解索引问题，数据类型不匹配，WHERE子句谓词问题以及更多其他任务，从而完成所有这些任务。作为DBA，这使您可以在用户受到重大影响之前主动解决性能问题。
DPA的表调整顾问可以帮助：
- 确定表中效率最低的查询
- 在表级别关联影响众多查询的问题
- 确定丢失的索引
- 发现具有大量读取和低百分比返回数据的查询，这可能是WHERE子句中的条件问题
- 重点关注WHERE子句中的谓词以确定模式和低效率
- 突出显示过时的统计信息
- 检测被称为“搅动”的插入，更新和删除事务的百分比
- 使您成为组织中的积极主动的DBA，有能力在对用户体验造成负面影响之前解决性能问题
要访问DPA中的Table Tuning Advisor，请从30天趋势页面上，单击屏幕右上方的TUNING选项卡。
在“ DPA调整”选项卡上，左侧显示查询顾问，而右侧显示表调整顾问。在屏幕的左上角，您可以通过单击下拉框选择最近30天的日期来查看前几天的建议。Query Advisor与上面演示的新功能匹配，但这只是一种以优先方式访问数据的新方法。右侧是新的Table Tuning Advisor，其表按优先级顺序列出，首先列出警报，然后是参考消息。
在此示例中，我们单击LineItem建议，并在左侧看到低效SQL语句的优先列表，在右侧列出了每个语句的详细信息。对于此表，单个查询计划是在步骤32、17和62多次扫描表，并且将从l_orderkey和l_tax的索引中受益。我们还可以看到使用相同索引可以改进的7条其他SQL语句。通过在表级别分析工作负载，解析查询计划并分解低效率的步骤来证明建议的合理性，我们就有机会创建一组索引来更正众多查询，从而在众多应用程序和流程中产生改进。
在此界面上，我们还将查看有关表的历史建议，以了解随时间的变化，可以通过界面左上方的日期下拉框选择该变化。
在索引建议的右侧，您可以单击“显示索引DDL”选项，这将弹出带有相应代码的以下屏幕。可以将代码复制到剪贴板以开始测试索引建议，以验证DPA的Projected Impact与您在测试环境中看到的改进相对应。
为了在表格基础上完成分析，在性能建议和理由下方是当前表格信息，包括常规元数据，平均数据流失（表格中插入，更新和删除事务的百分比），具有以下内容的现有索引和列它们的数据类型，空配置和默认值。在查看表时，此信息很有用，而不必使用其他工具。
