SQL调优指南笔记2：SQL Performance Methodology

Posted 2021-12-05 dingdingfish

本文为SQL Tuning Guide第2章“SQL 性能方法论”的笔记。

相关文档：Oracle Database 2 Day + Performance Tuning Guide

2.1 Guidelines for Designing Your Application

获得良好 SQL 性能的关键是在设计应用程序时已考虑到性能。

2.1.1 Guideline for Data Modeling

数据建模对于成功的应用程序设计很重要。
数据建模必须紧密配合业务需求。 将主要精力用于那些受最频繁业务交易影响的实体上。
在建模阶段，很容易花费太多时间对非核心数据元素进行建模，这会导致开发前导期过长。 使用建模工具（例如SQL Developer Data Modeler）可以快速生成模式定义，并且在需要快速原型时非常有用。

2.1.2 Guideline for Writing Efficient Applications

在系统开发的设计和架构阶段，确保应用程序开发人员了解 SQL 执行效率。为了实现此目标，开发环境必须支持以下特性：

1. 良好的数据库连接管理
   连接到数据库是一项成本高昂且不可扩展的操作。 因此，最佳实践是尽量减少与数据库的并发连接数。特别对于基于 Web 或多层应用程序，应使用池化数据库连接，而不是为每个用户请求重新建立连接。

2. 良好的游标使用和管理
   解析是解释 SQL 语句并为其创建执行计划的过程。 这个过程有很多阶段，包括语法检查、安全检查、执行计划生成以及将共享结构加载到共享池中。由于应尽可能减少解析，因此应用程序开发人员应将其应用程序设计为一次解析 SQL 语句并多次执行它们。 这是通过游标完成的。 有经验的 SQL 程序员应该熟悉打开和重新执行游标的概念。
   解析分为硬解析和软解析，可类比于物理读和逻辑读。硬解析更消耗资源。
   由于SQL和SQL解析结果可以共享，因此维护用户连接对于最小化系统上的解析活动同样重要。

3. 绑定变量的有效使用
   应用程序开发人员还必须确保 SQL 语句在共享池中共享。 为实现此目标，请使用绑定变量来表示查询中变化的部分。 请使用绑定变量而不要在 SQL 语句中使用写死的字符串文字。否则，SQL 语句很可能会被解析一次，然后永远不会被其他用户重用。

2.2 Guidelines for Deploying Your Application

要获得最佳性能，请像设计应用程序一样谨慎部署应用程序。

2.2.1 Guideline for Deploying in a Test Environment

测试过程主要包括功能测试和稳定性测试。 在此过程中的某个时刻，您必须执行性能测试。
以下列表描述了用于测试应用程序性能的简单规则。 此列表将为生产应用程序和应用程序上线后的容量规划过程提供重要信息：

1. 使用自动数据库诊断监视器 (ADDM) 和 SQL Tuning Advisor 进行设计验证。
2. 使用正确的优化器模式。
3. 测试单个用户的性能。
   实际上是测试可接受性，如果单用户通不过，并发用户更不可能通过。
4. 获取并记录所有 SQL 语句的计划。
   使用此过程可验证优化器是否正在获取最佳执行计划，并根据 CPU 时间和物理 I/O 了解 SQL 语句的相对执行成本。 此过程有助于识别未来需要最多调整和性能工作的高频度或重载事务。
5. 尝试多用户测试
   应测试执行 DML 语句的事务以确保没有锁定冲突或序列化问题。
6. 使用正确的硬件配置进行测试
   使用尽可能接近生产系统的配置进行测试。 使用真实的系统对于网络延迟、I/O 子系统带宽以及处理器类型和速度尤为重要。
7. 测量稳态性能
   进行基准测试时，重要的是要测量稳态条件下的性能。 每个基准测试运行都应该有一个加速阶段，在这个阶段用户连接到应用程序并逐渐开始在应用程序上执行工作。 此过程允许将频繁缓存的数据初始化到缓存中，并允许在稳定之前完成单次执行操作（例如解析）。 同样，在基准测试之后，缓降期是有用的，以便系统释放资源，用户停止工作并断开连接。

2.2.2 Guidelines for Application Rollout（应用上线）

当新应用推出时，通常采用两种策略：大爆炸法，所有用户立即迁移到新系统，以及涓流法，用户从现有系统慢慢迁移到新系统。这两种方法各有优缺点。前者与旧系统间的数据转换和同步较少，后者影响的用户范围较小。具体选择哪种依赖于全面严格的测试。