SQL报文优化：提升KingbaseES数据库性能的关键策略

📑前言

在数据库应用开发和运维过程中，SQL报文协议的选择往往被忽视，但它对数据库性能有着深远的影响。本文将通过一个实际案例，探讨如何通过优化SQL报文协议来显著提升KingbaseES数据库的性能表现。实验表明，合理使用Extended Query协议可使每秒事务处理量提升15.6%，为数据库性能优化提供重要参考。

文章目录

• 📑前言
• 一、KingbaseES协议基础
• • 1.1 两个阶段
  • 1.2 Extended Query协议
• 二、kbbench工具简介
• • 2.1 主要参数解析
  • 2.2 案例分析：SQL报文优化实践
• 三、小结

一、KingbaseES协议基础

1.1 两个阶段

KingbaseES通信协议包含2个阶段：startup阶段和常规normal阶段

startup阶段：客户端创建连接发送授权信息，如果正常服务端会反馈状态信息，成功创建，进入normal阶段。

normal阶段：客户端请求服务端，服务端执行命令并将结果带回客户端。

normal阶段，客户端能通过两种\"子协议\"来发送请求：

Simple Query：客户端发送请求，后端收到后处理并返回结果。

Extened Query：发送请求的过程被分为若干步骤.。

1.2 Extended Query协议

本篇主要对Extended Query协议进行详解。

Parse：客户端发送一个Parse消息给服务端，消息含参数化SQL，参数占位符每个参数的类型。 服务端收到该消息后，调用exec_parse_message函数处理，语法分析、语义分析和重写，并且创建一个Plan Cache的结构，用于缓存后续的执行计划。

Bind：客户端发送Bind消息，该消息携带具体的参数值、参数格式和返回列的格式。KingbaseES收到该消息后，调用exec_bind_message函数进行处理。为之前保存的Prepared Statement创建执行计划并将其保存在Plan Cache中，创建一个Portal用于后续执行。

Describe：客户端可以发送Describe消息获取Statment或Portal的元信息，即返回结果的列名，类型等信息，这些信息由RowDescription消息携带。如果请求获取Statement的元信息，还会返回具体的参数信息，由ParameterDescription消息携带。

Execute：客户端发送Execute消息告知服务端执行请求，服务端收到消息后，执行Bind阶段创建的Portal，执行结果通过DataRow消息返回给客户端，执行完成后发送CommandComplete。Execute消息中可以指定返回的行数，若行数为0，表示返回所有行。

Sync：使用Extended Query协议时，一个请求总是以Sync消息结束，服务端接收到Sync消息后，关闭隐式开启的事务并回复ReadyForQuery消息。

二、kbbench工具简介

kbbench是KingbaseES自带的性能测试工具。可以在并发的数据库会话中一遍一遍地运行相同序列的SQL命令，并且计算平均事务率（每秒的事务数）。默认情况下，kbbench会测试一种基于TPC-B但是要更宽松的场景，其中在每个事务中涉及五个SELECT、UPDATE以及INSERT命令。但是，也通过编写自己的事务脚本文件很容易用来测试其他情况。

2.1 主要参数解析

-c,--client=NUM：模拟的客户端数量，也就是并发数据库会话数量。默认为1。

-t,--transactions=NUM：每个客户端运行的事务数量。默认为10。

-T,--time=NUM：运行测试多少秒，而不是为每个客户端运行固定数量的事务。-t和-T是互斥的。

-M,--protocol：要用来提交查询到服务器的协议：•simple：使用简单查询协议。•extended使用扩展查询协议。•prepared：使用带预备语句的扩展查询语句。在prepared模式中，kbbench重用从第二个查询迭代开始的解析分析结果，因此kbbench运行速度快于其他模式。默认是简单查询协议。

-f,--file=FILENAME：把一个从\"filename\"读到的事务脚本加入到被执行的脚本列表中。

-r,--report-latencies：在基准结束后，报告平均的每个命令的每语句等待时间（从客户端的角度来说是执行时间）。

2.2 案例分析：SQL报文优化实践

第一次压测：Simple Query协议

报告显示Parse Reused%为0，即解析重用率为0；Plan Reused%为0，计划重用率为0。此处已经找到性能优化的点了，即提升SQL解析和计划重用率。

报告中重点关注%数据库时间那一列，可以看到数据库时间主要被分解为：

• Parse Time：语法解析时间9.61%
• Analyze Time：语义分析时间13.1%
• Rewrite Time：SQL重写时间1.75%。
• Plan Time：计划时间22.27%
• Execute Time：执行时间19.21%

以上三个解析时间加一块是24.46%，在加上计划时间一共是46.73%，如果能把这部分时间通过扩展SQL协议省下来，那么性能得到较大提升。

整个负载期间，90.9%是Simple Query报文，导致解析和计划无法重用。

查看KDDM报告，确实给出了使用扩展SQL协议的建议，也给了一些其他的建议，需要DBA自己根据情况去判断是否采用。

这里我们采用使用扩展SQL协议的建议，即给kbbench指定-M参数为Prepared即可。其他的像JDBC等也可以通过连接串指定SQL交互协议。

第二次压测：Extended Query协议

对比分析：

• 结果解析和计划次数急剧下降，现在为每秒1以上，说明解析和计划已经重用。
• 执行次数12950.31，之前为11202.75，也有所提高。
• 每秒事务处理量由原来的2241提升至2591，实现了显著的性能增长。

SQL解析和执行计划的重用率均达到了预期的100%，系统成功实现了SQL解析结果和执行计划的完全重用。

三、小结

SQL报文优化实践表明，通过将Simple Query协议切换为Extended Query协议，可显著提升数据库性能。优化后，解析与计划重用率达100%，每秒事务数提升15.6%。合理利用Prepared Statement机制，能有效降低SQL解析开销，是数据库性能调优的关键策略之一。