目前，数据库是绝大多数应用系统储存数据的主要工具。当用户系统需要访问数据库时，需要使用 SQL 把应用的指令告诉数据库。因此 SQL 是应用与数据库系统“沟通”的重要手段，SQL 性能的好坏将直接影响“沟通”的效率，进一步地会影响到系统的用户响应时间、系统吞吐量、IT 设置成本等。

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

OceanBase 社区版教程直播第七期，将为你带来“SQL 诊断与调优”更多干货信息。

惊喜直播预告：《如何对 OceanBase 性能诊断和调优》

1 月 25 日（周二）19:30，OceanBase 社区版教程直播将迎来第七期：如何对 OceanBase 性能诊断和调优。本次直播，OceanBase 高级开发工程师义博将一次性为你讲透关于“性能诊断和调优”的几大知识点。

● 一条 SQL 从应用到 OceanBase 中执行经过了哪些流程？同一类 SQL 反复执行 OceanBase 又会怎样重用执行计划？

● 如何使用 OceanBase 中的各种视图来做 SQL 诊断？

● 对于一条慢 SQL，我们可以从哪些方面来优化它的执行性能？

以上内容将帮助你解决以下痛点：

● 想要对运行在 OceanBase 上的 SQL 进行诊断，但 OceanBase 提供的各种视图让人眼花缭乱，无从下手。

● 发现一条 SQL 在 OceanBase 上执行很慢，想要优化 SQL 的执行性能，却无处下手

学完本期教程直播，你将能轻松应对以下问题：

● 如何利用 OceanBase 提供的各种视图诊断 SQL。

● 如何使用一些常见的 SQL 调优手段来优化 SQL 在 OceanBase 中的执行性能。

01 为什么要进行 SQL 诊断与调优

很多人可能会说，我只要把每一条 SQL 都写好，保证 SQL 跑得快不就行了么，这样还省去了后面做 SQL 诊断和调优了。对于这个说法，我们只能说，对但不全对。

首先，写出一条“好”的 SQL 并不容易，它要求写 SQL 的人对数据库的原理和业务需求都有很深入的理解。而一般情况下，开发人员往往都是聚焦于业务需求，对数据库的理解相对不深，DBA 则难以保证对每一个业务都如数家珍。

其次，大型系统中 SQL 的数量往往非常庞大，业务的需求也在不断变化，很难有足够多的专业 DBA 与业务研发一起优化好每一条 SQL。

再次，即使是一条已经优化好的 SQL，随着数据量的变化或者数据库版本的升级也存在性能变差的可能，进而存在潜在的风险。

因此，无论是正在开发建设的应用系统，还是已经在线上稳定运行的应用系统，都需通过 SQL 诊断来识别风险，通过调优来解决性能瓶颈、保障系统稳定。

02 OceanBase SQL 诊断的常规手段

在使用分布式数据库的时候，你是否遇到过诸如此类的烦恼：

痛点 1：我的集群中有很多 server，怎么查看集群中的 SQL 请求流量是否均匀？

痛点 2：数据库中跑着这么多 SQL，我要如何从中找到这几类 SQL：消耗 CPU 最多的 SQL，某段时间内请求次数排在 TOP-N 的 SQL，或某段时间内平均 RT 排在 TOP-N 的 SQL？

痛点 3：集群正在稳定运行，但是 SQL 的 RT 突然抖动了，怎么找到引起抖动的 SQL？

针对以上三项痛点，其实，OceanBase 的 [G]V$SQL_AUDIT 视图就可以解决你的烦恼。[G]V$SQL_AUDIT 是 SQL 诊断时最常用的一个视图，记录了每一次 SQL 请求的来源、执行状态及各种统计信息。使用这个视图我们可以查看任意一条 SQL 的计划类型、是否命中计划缓存、执行耗时、等待事件、是否存在重试等等。通过一些简单的 SQL ，我们便可以从这个视图中查出各种需要的信息。

下面我们举几个例子。

例一：想要查看集群中 SQL 请求流量是否均匀。

思路：我们首先可以查出某个时间段内数据库中所有 SQL 并按照 server 级别进行聚合，再统计该时间段内每台机器上的 QPS。

如下的 SQL 查出了前一秒各个 server 中的 SQL 请求数量。不难发现，SQL 请求集中在了 192.168.35.138 和 192.168.14.0 两台机器上，而 192.168.35.111 和 192.168.14.60 两台机器上 SQL 请求的数量相对较少。

select t2.zone, t1.svr_ip,  count(*) as QPSfrom oceanbase.gv$sql_audit t1, oceanbase.__all_server t2where t1.svr_ip = t2.svr_ip and t1.tenant_id = 1001and IS_EXECUTOR_RPC = 0 and request_time > (time_to_usec(now()) - 1000000)and request_time < time_to_usec(now())group by t1.svr_ip   order by QPS;+---------------+----------------+------+| zone          | svr_ip         | QPS  |+---------------+----------------+------+| cn-hangzhou-h | 192.168.14.60  |  705 || cn-hangzhou-i | 192.168.35.111 | 1485 || cn-hangzhou-h | 192.168.14.0   | 3119 || cn-hangzhou-i | 192.168.35.138 | 4959 |+---------------+----------------+------+

例二：找到某个时间段请求次数排在 TOP-N 的 SQL。

我们可以查出某个时间段内数据库中的所有 SQL，按照 SQL_ID（每条 SQL 的唯一标识符）聚合，并统计每个 SQL_ID 的数量，其中数量排名前 N 的 SQL_ID 就是我们要找的 TOP-N SQL。如下的 SQL 查出了前一秒执行次数排前 10 SQL 的 SQL_ID、执行次数和执行时间。基于这个结果我们可以进一步分析这些 SQL 中是否存在需要进一步优化的 SQL。

select SQL_ID, count(*) as QPS, avg(t1.elapsed_time) RTfrom oceanbase.gv$sql_audit t1where   tenant_id = 1001       and IS_EXECUTOR_RPC = 0and request_time > (time_to_usec(now()) - 10000000)and request_time < time_to_usec(now())group by t1.sql_id order by QPS desc limit 10;+----------------------------------+------+------------+| SQL_ID                           | QPS  | RT         |+----------------------------------+------+------------+| BF7AA13A28DF50BA5C33FF19F1DBD8A9 | 2523 |  4233.2085 || CE7208ADDE365D0AB5E68EE24E5FD730 | 1268 |  5935.8683 || E5C7494018989226E69AE7D08B3D0F15 | 1028 |  7275.7490 || D0E8D8C937E44BC3BB9A5379AE1064C5 | 1000 | 12999.1640 || 2D45D7BE4E459CFBEAE4803971F0C6F9 | 1000 |  8050.6360 || C81CE9AA555BE59B088B379CC7AE5B40 | 1000 |  6865.4940 || BDC4FE903B414203A04E41C7DDA6627D | 1000 | 12751.8960 || B1B136047D7C3B6B9125F095363A9D23 |  885 | 13293.2237 || 47993DD69888868E92A7CAB2FDE65380 |  880 |  7282.0557 || 05C6279D767C7F212619BF4B659D3BAB |  844 | 11474.5438 |+----------------------------------+------+------------+

当然除了[G]V$SQL_AUDIT，OceanBase 还提供了[G]V$PLAN_CACHE_PLAN_STAT、[G]V$PLAN_CACHE_PLAN_EXPLAIN 等视图用于 SQL 执行计划的诊断。合理地使用这些视图可以让 SQL 诊断事半功倍。

03 OceanBase SQL 调优的常用手段

当我们发现某一条 SQL 存在性能问题时，我们可以通过很多方式对这条 SQL 进行优化，其中最常见的是索引调优。索引调优通过为数据表创建合适的索引来达到减少数据扫描量，消除排序等目的。索引调优是一种比较简单的调优方式，也是 SQL 出现性能问题时通常在第一时间考虑的优化方式。在单表扫描场景下创建一个合适的索引往往可以极大地提高 SQL 的执行性能。

在建索引前，我们需要考虑是否有必要建索引、应该在哪些列上建索引、索引列的顺序应该怎样安排。

在建索引时，一个最基础的策略是将存在等值条件的列放在索引的前面，将存在范围条件的列放在索引的后面，有多个列上存在范围条件时将过滤性强的列放在前面。例如一条 SQL 中存在三个过滤条件，分别是 a = 1、b > 0、c between 1 and 12。其中 b > 0 可以过滤掉 30%的数据，c between 1 and 12 可以过滤掉 90%的数据，那么按照我们的基础策略，对于这条 SQL 可以在 (a, c, b) 上建一个索引进行优化。当然这个基础策略也不是万能的，在实际优化时往往需要结合实际场景，具体问题具体分析。

除了索引调优外，还有连接调优、SQL 语句调优等多种调优手段，受于篇幅限制没法详细讲解，更多详细内容欢迎大家来收看 1 月 25 日 19:30 OceanBase 社区版教程直播第七期：如何对 OceanBase 进行 SQL 诊断和调优。

往期推荐:

开源实践 | OceanBase 在红象云腾大数据场景下的实践与思考

2021 OceanBase 年度报告 | 用技术让海量数据的管理和使用更简单！

2021 OceanBase 开源半年度报告 | 不忘初心，感恩同行

全面提升体系化数据管理能力 | OceanBase 发布全新3.X工具家族

参与更多技术交流，请至 OceanBase 社区版【问答区】。