数据库作为绝大多数应用系统储存数据的核心系统，在用户系统需要访问数据时，有着至关重要的作用。在这些交互中，SQL 语言是应用与数据库系统之间“沟通”的桥梁，它负责将应用的指令传达给数据库。因此，SQL 的性能好坏直接决定了这种“沟通”的效率，进而对系统的用户响应时间、系统吞吐量以及IT设置成本等关键指标产生影响。

那么，什么是 SQL 诊断与调优？

SQL 诊断就是通过一些技术手段来找出“沟通”效率不高的原因或潜在影响“沟通”效率的因素，比如发现执行性能不佳的 SQL、可能存在性能瓶颈的 SQL 等。而 SQL 调优则是通过一系列的技术手段，来提高 SQL 的执行效率，解决 SQL 的性能瓶颈，从而达到提高应用与数据库“沟通”效率的目的。

《DBA 从入门到实践》第七期将在5月22日（周三）如期而至，为大家讲解：

• ODP（OceanBase Database Proxy） SQL 路由原理。
• 如何分析 SQL 监控视图。
• 如何阅读和管理 OceanBase SQL 执行计划。
• 最常见的 SQL 调优方式。
• SQL 性能问题的典型场景和排查思路。

点击下方链接报名学习

【DBA从入门到实践】第七期

内容抢“鲜”知

（一）ODP 路由原理

路由是 OceanBase 分布式数据库中的一个重要功能，是分布式架构下，实现快速访问数据的利器。

Partition 是 OceanBase 数据存储的基本单元。当我们创建一张 Table 时，就会存在表和 Partition 的映射。非分区表中，不考虑主备时，一张 Table 对应一个 Partition；分区表中一个 Table 会对应多个 Partition。

路由实现了根据 OBServer 的数据分布精准访问到数据所在的机器，还可以根据一定的策略将一致性要求不高的读请求发送给副本机器，充分利用机器的资源。路由选择输入的是用户的 SQL、用户配置规则、OBServer 状态，路由选择输出的是一个可用 OBServer 地址。

其路由实现逻辑如下图所示：

（二）分析 SQL 监控视图

OceanBase 数据库 V4.x 版本中有着非常丰富的视图，通过这些视图可以获取 OceanBase 集群各种数据库对象的基本信息和实时状态信息。这些视图分为两大类：数据字典视图和动态性能视图。

丰富的视图展示了 OceanBase 数据库的内部架构及系统运行的详细状态。通过视图，我们可以便捷地查看 OceanBase 数据库的系统组成及实时状态，了解组件之间的关系，内部视图是学习 OceanBase 数据库的最好途径之一，其相应的数据字典视图见下图。

监控指标相关的数据来源于 OceanBase 数据库内部的动态性能视图，所有监控指标都可以通过 SQL 语句进行访问。动态性能视图分为 GV$ 视图和 V$ 视图，外部监控系统（例如 OCP）通过在每个数据库服务器上部署代理进程，通过 SQL 接口定期拉取本机上的监控信息（V$ 视图），部分全局信息（例如 Root Service 相关）通过中心节点采集。监控数据统一汇报给监控系统数据库，并按照各种维度聚合（集群维度、租户维度、节点维度、Unit 维度），从而构建整个监控大盘。

（三）如何阅读和管理 OceanBase SQL 执行计划

执行计划（Execution Plan）是对一条 SQL 查询语句在数据库中执行过程的描述。用户可以通过 EXPLAIN 命令查看优化器针对指定 SQL 生成的逻辑执行计划。如果要分析某条 SQL 的性能问题，通常需要先查看 SQL 的执行计划，排查每一步 SQL 执行是否存在问题。因此，读懂执行计划是 SQL 优化的先决条件，而了解执行计划的算子是理解 EXPLAIN 命令的关键。

（四）最常见的 SQL 调优方式

当用户已经学习完如何通过 EXPLAIN 命令查看优化器针对 SQL 生成的逻辑执行计划，以及如何通过 Hint 和 Outline 来人为控制优化器的行为，使优化器生成指定的计划。就可以以上述内容为基础，继续了解 OceanBase SQL 性能调优中最基础的内容：第一部分是统计信息和计划缓存的介绍，第二部分是 OceanBase 数据库的使用者需要了解的几种性能调优手段。

（五）SQL 性能问题的典型场景和排查思路

当用户完成了如何阅读和管理 SQL 的执行计划，以及常见的几种 SQL 调优方式，就获得了学习这一小节的基础知识。当用户遇到由于 SQL 原因导致的性能问题时，一般可以通过以下几个步骤进行排查：

1. 通过全链路追踪确认各阶段耗时占比，确认耗时长的阶段是什么？
2. 如果上一步显示慢在 observer 模块，则可以通过 oceanbase.gv$ob_sql_audit 分析具体是 observer 内的什么阶段耗时长了？
3. 如果上一步耗时长的阶段在执行阶段，则先根据上文的内容判断是否存在 buffer 表、大小账号、硬解析等问题？
4. 如果上述问题均不存在，则需要通过 explain extended 展示的执行计划来分析优化器的估行和真实行数是否有巨大差距，如果有明显差距，则需要手动收集统计信息。否则就进一步考虑是需要创建更合适的索引、通过 hint 调整计划形态、通过 hint 调整并行度等。

在该小节中，首先会为大家展示上面排查步骤中提到的几个常被用于进行 SQL 性能问题分析的工具，然后介绍如何通过这几个工具找到 SQL 性能优化的方向，最后会对 SQL 调优的最典型的场景和常见问题进行一个汇总。 

更多精彩内容请锁定5月22日《DBA从入门到实践》第七期~