专家实录｜TaurusDB极致弹性与性能优化的技术实践

本文作者：华为云数据库软件总工程师彭立勋

在公有云云原生环境下，大家比较关注极致弹性和性能优化，对TaurusDB而言，必须在这两方面为客户提供很好的支持，也对此做了很多的优化。

点击观看视频

越来越多用户开始使用Serverless模式。Serverless的特点是，无法提前知晓用户流量的大小，而需要根据Workload动态调整资源，使资源能够承载当前的业务流量负载。

游戏场景下的波峰波谷非常明显。一款游戏如果突然爆火，流量将瞬间冲到10倍、20倍，此外，多数游戏在一天内会呈现固定的高峰时段，如下班后、睡觉前，数据库则需要在不同的周期和时间点提供相匹配的资源。

电商场景下每年有固定的促销点，流量比平时高出几十倍甚至上百倍，也需要在很短的时间内对资源进行扩容。当出现爆品时，客户并不能提前知晓流量的大小，因此扩容并不能完全依赖于客户自己的判断，更需要依赖系统本身的快速弹性扩容能力。

Serverless模式改变了传统数据库“提前预估资源、买固定资源，或先算好资源再在云上部署”的模式，会在用户指定的资源上下限的范围内根据Workload自动调整，达到单节点上限后可以增加节点继续分摊流量。

在此过程中，负载调度能力尤为关键，包括两个部分：管控调度、后端内核在线弹性调整，其中内核需具备“支撑调度对用户无感”的特性。管控调度也非常重要，因为弹性调度并非是单纯依靠纯内核来完成，早期Serverless采用后置调度——当发现资源富余降低规格，发现资源不足提高规格，虽然可以把监控粒度做到秒级，但在调度过程中要么用户业务已经受损，要么资源浪费已经发生，因此后置调度并不是很及时。

在华为内部软件比赛中，我们将Serverless调度问题抽象为一个纯算法问题，发现通过提前学习客户的Workload，综合考虑不同类型Query的执行容忍度综合进行智能调度算法，最后总成本只占后置调度总成本的不到30%，可见管控调度是非常重要的。

传统的数据库倒换过程往往会使用户感知到明显的闪断，TaurusDB的ALT技术能够做到大部分场景对用户透明。

在倒换过程中，需要先保存原资源上节点的上下文，在节点倒换后连接新的节点。如果没有保存，即使完成节点倒换，也会因关键变量的丢失、SQL执行上下文的依赖缺失，导致后续SQL执行结果异常。

业界曾用的“缓存用户执行SQL，倒换后重放”等方法因为没有上下文的关联和连接性，依然无法保证执行结果的正确性。要真正实现倒换后上下文的准确性，关键在于保存所有连接的上下文状态，并在新节点重放出来，才能达成一致性状态。

当物理资源紧张时，进程内存的动态调整非常频繁。而在传统内存管理中，部分内存参数支持在线调整，部分则完全不支持，还有部分虽有参数但无法精确控量，从而制约了内存调度的效率。

TaurusDB对此做了针对性改造：针对有参数控制的内存，优化变更速度，尤其是对整体效率影响最大的慢Buffer Pool；针对不支持在线调整的内存，改为在线可调；针对有参数但无法精确控制的内存，进行精确控制；针对完全无法控制的内存，将其用量尽量控制到较小的比例，确保不影响整个内存的调度。

TaurusDB还对Buffer Pool做了很大的优化。传统的内存管理是以哈希表的方式进行管理，内存结构固定后难以动态变更，若调整内存数量，需要全量拷贝哈希表，不仅耗时久，且不能在初始阶段合理申请大量内存，容易陷入临界状态。

TaurusDB设计了127、255等关键内存阶梯阈值，在阶梯内调整Buffer Pool是完全无感的，仅需把内存挂上去，避免了额外的开销；当内存调整需跨阶梯（如突破256）时，虽然初始化内存结构相对慢一些，但TaurusDB已经进行了并行初始化的优化。经过实测，无论Buffer Pool内存是向上扩容还是向下缩容，即便是在跨阶梯的临界调整场景下，整个过程耗时均不超过1秒，彻底解决了传统Buffer Pool调整慢的核心问题。

关于IO，如果将用户的页面全部存储在固定的物理资源上，那么当用户需要扩容时，就会由于物理资源的耗尽而无法弹性调整。因此，必须将IO打散并做充分的弹性调度。

TaurusDB的解决方案，是进行底层资源的精细化管理，将数据页面映射至不同来源的物理资源，对应的物理资源完全分散，系统只需维护映射关系即可实现灵活调度。如此一来，即使上层计算层识别出某张表为访问热点，当数据下沉到底层存储时，热点表的不同页面已分散在各个物理资源上 ，底层物理资源的访问压力始终保持均衡，既支持更大容量的扩展，又能充分利用所有物理资源的IOPS（每秒输入输出操作）能力。

在电商等应力侧场景中，常遇到“大批量ID查询”需求，如单次传入数万甚至数十万产品ID，通过IN条件查询数据库。TaurusDB的SQL层使用的是MySQL并复用其优化器逻辑，而MySQL在处理这类查询时存在明显瓶颈：一方面，MySQL依赖索引优化IN查询，但IN列表中ID数量过长时，会触发内部参数限制，导致查询从“索引扫描”改写为“全表扫描”；若强行调大参数避免降级，又极易引发内存溢出（OOM）。另一方面，MySQL原生逻辑会将IN列表中每个ID转为独立操作对象（单个约占 230 字节），当传入10万甚至100万 ID时，仅这部分内存开销就极为庞大，对数据库稳定性造成严重威胁。

在应对大批量IN查询时，部分用户会通过改写SQL来优化性能：先将IN条件中的大量ID存入临时表，借此触发MySQL的“半连接物化”策略 ——MySQL优化器会自动将原IN查询逻辑转换为“临时表与外层表的条件关联”，且支持灵活选择“内表驱动外表” 或“外表驱动内表”的关联方式，以此避免全表扫描。但实际场景中，许多用户面临“程序不可改”的限制，无法通过手动改写SQL实现上述优化。

针对这一痛点，TaurusDB的解决方案是：在不改变用户原始SQL写法的前提下，通过引入定制化算子+阈值触发机制，自动实现等效优化：

• 预设一个IN列表长度阈值，当检测到查询中IN条件的ID数量超过该阈值时，自动触发转换逻辑；

• 由算子将IN条件中的大量ID自动“物化”为临时结构（无需用户手动建表）；

• 基于物化后的临时结构，自动启用半连接物化策略，将原IN查询转化为高效的关联查询，最终达到与“手动改写成临时表”相同的优化效果，从根本上避免查询降级为全表扫描。

另外一种场景，常见于用户编写的“关联子查询”SQL中，外层表查询时有特定过滤条件，而内层表查询会引用外层表的查询条件去进一步匹配数据，这种强关联特性，决定了内层子查询无法提前物化，只能由外层表驱动执行。

如上图，若按常规优化路径执行，流程会非常低效：以“外层表为t1、内层表涉及 t1.b字段”的查询为例，系统会先遍历t1表中的每一条记录，将当前记录的t1.b字段值传入内层子查询；执行子查询后得到一组a值结果，再判断t1表当前行的 t1.a字段值是否在这组a值中；确认匹配后，才会保留这条记录并继续处理下一行。整个过程中，若外层表t1的t1.a字段存在大量重复值，也需要重复执行很多遍，因为t1.a和t1.b是确定的情况下，对应的内层子查询结果就是固定的，这会产生大量冗余计算。

TaurusDB通过算子优化引入了PTRC半结构缓存机制，核心思路是“缓存确定条件下的固定结果，减少重复计算”。

优化后的执行流程变为：

若已缓存，直接调取缓存的结果，无需重新执行内层子查询；

若未缓存，执行一次内层子查询，将得到的结果与当前Key关联后存入PTRC缓存，供后续相同Key的记录复用。

通过这种“按需缓存、精准复用”的半结构缓存设计，TaurusDB大幅减少了内层子查询的重复执行次数，在t1.a字段重复率较高的场景下，能显著降低执行器负载，提升关联子查询的整体执行效率。

与此前通过改写执行逻辑实现优化的方案不同，PTRC 算子的优化思路并未改变执行器核心逻辑，而是在执行路径中增加了缓存机制——通过拦截重复的物理执行请求，减少不必要的计算开销，本质上是一种 "路径优化型" 算子。

如果PTRC生效，执行计划中会显示“Result cache”，记录以t1.a和t1.b为Key的缓存逻辑，后续遇到相同Key时，不再执行子查询物理计算，直接返回缓存结果，这对用户而言是一种高效且透明的优化方式。

实测数据显示，启用PTRC的优化效果会比未启用提升5倍甚至更多。同时，为避免缓存机制引入新的问题，TaurusDB设计了完善的可控性策略：

这种 "按需缓存、智能启停" 的设计，既保证了缓存机制的优化效率，又避免了盲目缓存带来的副作用，使PTRC算子能在各类关联子查询场景中稳定发挥价值。

从公有云云原生环境的核心需求出发，TaurusDB以极致弹性、极致性能为核心目标，进行了Serverless、应用无损透明ALT、资源调度、IO弹性平衡设计、查询执行以及在性能等方面的技术优化，为用户提供稳定、高效、灵活的数据库服务，帮助企业业务增长无瓶颈、资源使用无浪费。