性能竞赛优秀项目 | 以「点」窥面，PointGet 性能优化分享

在分布式数据库 TiDB 中如何更好的提高查询的吞吐量和提升查询的性能一直是一个难题。PointGet 虽小，但我们可以从 PointGet 中窥探出 TiDB 的特性变迁。PointGet 由于查询方式固定，所以就被剥离出来抽象成了一条特殊的 Plan，这样可以更准确的去做相应的优化。为了更好的从整体流程和针对优化方面学习 TiDB，我们特意挑选了 PointGet 来作为突破口来优化上述提到的性能，这样就可以站在巨人的肩膀上专门去优化 TiDB 抽象出来的 PointGet 相关逻辑，更加 Focus 在有意义和创造力的地方。

我们团队有三位队友和一位顾问，从比赛一开始顾问就和我们沟通了各自对于这个赛题的想法和观点。我们提出了很多没有基于现实情况的假设，顾问指出了很多我这边臆测的问题点，也为后面定位问题和解决问题提供了非常良好的帮助。同时，我们也参加了 TiDB 在 B 站的 Talent 计划，根据视频的内容对现有的 TiDB 有了更加深入的理解，更好的支撑了我们对于完成这个赛题的信心。

PointGet 是一个简单的点查，展示 SQL 如下

SELECT * FROM user WHERE id = 1;

PointGet 的执行流程 

本文先把 TiDB 官方的流程图贴在下方，这样更好的能让大家对整体的 SQL 流程有个感知。图中客户端发起请求，TiDB 的服务端接收到对应的数据包，服务端 Parse、Valid 等步骤生成 AST，接着通过逻辑优化和物理优化生产对应的执行计划，并通过对应的执行算子去执行对应的 Plan，然后通过 RPC 去访问 TiKV 获取对应的数据。

SQL 查询流程

从上图的流程图我们可以看出来，PointGet 有自己的 PointGet Plan 和 PointGet Executor。

根据上面的情况我们可以发现以下几个优化点：

• PointGet 是一个非常简单的点查，基本可以理解为一个查询一个结果；

• PointGet 是一个点查操作，配合 Lock 的特性可以大大增加可靠性和稳定性；

• 无论几次 Query 都会访问 TiKV，第一次查询可以访问 TiKV，后面的查询可以直接复用以前查询的结果。

设计优化 PointGet 问题点的解决方案 

面对以上优化点，我们设计一个方案来解决上面提到的问题，这个方案涉及到了 DDL 和 DML 相关模块，DML 流程图展示如下：

TiDB 中 Cache 更新的及时性和内存管理问题 

• 如果有多个 TiDB，DDL 的时候如何保证查询结果的一致性？
• 如果查询的表数据过大，缓存的 Cache 会不会直接造成 TiDB 的 OOM？
• 引入新的代码是否符合社区的发展方向？

性能测试

额外发现

在我们做 Benchmark 的时候，发现表即使是在 Lock 状态时，Update 等语句也可以正常执行，这并不符合 Lock 的语义。

我们当天整理了一下问题并且提出了 Issue，PingCAP 的官方很及时的做出了响应，并且在接下来的几天内就解决了问题并且增加了对应的测试用例，非常具有及时性，值得点赞。

总结