TiDB 6.5 新特性解析丨过去一年，我们是如何让 TiFlash 高效又稳定地榨干 CPU？

TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版，携带了诸多备受期待的新特性：产品易用性进一步提升、内核不断打磨，更加成熟、多样化的灾备能力、加强应用开发者生态构建……

TiDB 6.5 新特性解析系列文章由 PingCAP 产研团队重磅打造，从原理分析、技术实现、和产品体验几个层面展示了 6.5 版本的多项功能优化，旨在帮助读者更简单、更全面的体验 6.5 版本。

本文为系列文章的第一篇，介绍了 TiFlash 在高并发场景下的稳定性和资源利用率的优化原理。

缘起

最近的某天，我们测试 TiFlash 在高并发查询场景下的稳定性时，发现 TiFlash 终于可以长时间稳定将 CPU 完全打满，这意味着我们能充分的利用 CPU 资源。回想一年多前，我们还在为高并发查询下的 OOM（out-of memory）、OOT（out-of thread）、CPU 使用率不高等各种问题而绞尽脑汁。是时候来回顾一下我们做了哪些事情，让量变引起质变。

👆 CPU 使用率打满

我们都知道，对于分析型的查询来说，有时候一个请求就能将机器的 CPU 资源打满。所以，大部分 OLAP 系统在设计和实现的时候，很少考虑系统在高查询并发下的表现——早期的 TiFlash 也没在这方面考虑太多。

早期的 TiFlash 的资源管理比较初级——没有高效的线程管理机制、缺少健壮的查询任务调度器、每个查询的内存使用没有任何限制、最新写入的数据存储和管理也有较大优化空间。这些优化措施的缺位，导致早期的 TiFlash 在高并发查询场景下表现不佳，经常无法将 CPU 使用率打满，稍有不慎还可能出现 OOM 或 OOT。

过去一年里，针对 TiFlash 在高并发场景下的稳定性和资源利用率这个问题