大家好，我叫柯益思
一枚程序猿，从事数据库开发工作
你敢相信吗？我...居然重生了！！！
我...居然重生了
上一世，在国产数据库百团大战中，我站错了队伍，公司惨遭市场淘汰，中年失业，最后落魄一生，郁郁而终...
这一世，带着前世的记忆和对未来的洞察，凭借先知者的优势，我势必一雪前耻，站在胜利者的行列重新夺回属于自己的荣耀！
打不过就加入
俗话说，站在风口上，猪都能飞起来~
现在是北京时间2024年1月1日，仍处在国产数据库行业的风口上。
伴随着“战争”带来的硝烟弥漫，在残酷的“下半场”淘汰赛即将开启之际，我加入了属于我的的风口--金仓数据库，准备大展拳脚。
看，缘分就是那么妙不可言，柯益思VS KES
上一世我到底错过了什么？
OMG！
钮钴禄氏·柯益思
从上文你应当看出来了，我是一只有追求的程序猿，重生后去大A当股神实非我愿（毕竟股市水太深，股神和韭菜/天堂与天台之间有时候也就一念之间）~
研究高性能的数据库才是我的真爱与使命！
譬如现在，我正在研究一个关键问题：
“在高并发、大数据量的TP业务场景下，如何提高业务系统的性能？”
执行计划缓存，KES性能飞跃的秘密
研究中，我们发现执行计划缓存如同一把隐形的钥匙，能够解锁系统性能的无限潜能。
执行计划，是数据库管理系统在接收到SQL查询后，经过解析、优化等阶段生成的执行蓝图。而执行计划缓存，则是数据库管理系统为了提升查询效率，将这些精心计算的执行计划存储起来，以便在后续遇到相同或相似的查询时，能够直接复用，避免重复劳动。这大大减少了查询编译的时间开销，是提升业务系统性能的关键一环。
金仓数据库支持两种执行计划缓存方案。
1
KING BASE
进程本地内存的执行计划缓存方案
金仓数据库本地的执行计划缓存方案是每个用户连接在本地进程内存中保存各自的执行计划，由客户端来控制执行计划缓存的行为。
以一个JDBC客户端为例。JAVA程序首先定义一个PreparedStatement对象，SQL中常量全部以参数标识。每次当需要发送SQL请求时，将参数赋值并发送请求到客户端。通过这种方式，可以保证同样形式的SQL(只有常量不同)可以重用相同的执行计划，从而提高执行计划的利用率。
在数据库所在的服务器内存资源充足，并且数据库的客户端能够按照这种参数化的格式发送SQL的情况下，这种执行计划缓存的方式的性能最好。
执行本地内存的计划缓存性能测试结果：
对于使用本地内存的执行计划缓存和不使用执行计划缓存的场景，TPC-C的测试结果表明，在启用执行计划缓存后，通过使用进程本地执行计划缓存的方式，系统的性能可提升1.6倍！
数据集：TPCC 1000 Warehouses,100G
测试服务器：HiSilicon Kunpeng-920 96c
未使用执行计划缓存，tpmC为92万，使用执行计划缓存，tpmC为148万。
然而，本地执行计划缓存方案并非适用于任何场景。一方面，本地执行计划缓存将会占用过高的内存；另一方面如果用户不能按照参数化的格式发送SQL请求本地执行计划缓存的重用率不高。在有限的CPU和内存资源场景下，本地内存的执行计划缓存方案将会产生性能瓶颈，无法达到预期的性能优化目标。
当问题从“在高并发、大数据量的业务场景下，如何提高业务系统的性能？”转向“在高并发的业务场景下，如何利用有限的CPU和内存资源，高效的处理SQL请求，从而提高整个业务系统的性能？”后，金仓数据库共享内存的执行计划缓存方案闪亮登场。
2
KING BASE
共享内存的执行计划缓存方案
为了解决执行计划缓存占用内存高的问题，金仓数据库采用了在共享内存中保存执行计划的方案。
金仓数据库共享内存的执行计划缓存方案是每个连接不再保存执行计划，而是从共享内存中存取执行计划。通过这种方式，执行计划缓存的空间不再受到客户端连接数的影响，并且可以进一步提高缓存计划的复用率。当执行计划缓存占用空间达到门限值时，数据库会释放一定比例重用率比较低的执行计划，从而保证内存占用在一个可控的范围之内。
此外，为了解决SQL中带有常量从而执行计划缓存复用率不高的问题，数据库在接收到SQL之后，首先会进行常量的参数化，即将SQL中的常量替换为参数，然后根据参数化后的SQL去查询执行计划缓存。通过这种方式保证多条SQL如果只有常量不同，他们可以重用相同的执行计划。
执行共享内存的计划缓存性能测试：
在有限的CPU和内存资源场景下，当将缓存方案从本地内存的执行计划缓存改为采用共享内存的执行计划缓存方案后，数据库不再成为整个系统的性能瓶颈。
数据集：业务系统数据量20G，涉及800多种不同的SQL语句
测试服务器：Intel(R) Xeon(R) Platinum 8268
在数据库的压力逐渐增加到5万并发过程中，整个系统的TPS在稳步的增长，波动幅度很小。到5万并发时，TPS稳定在1500左右。经过几个小时的运行，一直非常稳定。
其次，整个数据库系统占用的内存从1.2T降低至200G，并且随着并发连接数量的增加，整个数据库系统占用的内存增幅不大。
3
KING BASE
精准施策，KES的两套方案
综上所述，我们设计的两套执行计划缓存方案可以满足不同业务场景下系统对性能的要求：
当系统内存充足并且客户端的程序能够按照数据库要求的格式发送SQL语句时，本地缓存的执行计划效率更高。
当系统内存资源有限，并发数量大，并且用户发送的SQL语句直接带有常量时，采用共享内存的方案效果更好。
在实际应用中，用户可以根据业务系统的特点和需求，选择合适的缓存策略，并结合执行计划缓存等优化手段，共同提升系统的整体性能。
因为数据库支持两种通信协议，所以目前实现的方式是每种协议对应一种执行计划缓存的方法。在将来的版本中，我们会研究将这两者融合成一套方案。
没有终点
我叫柯益思~
前世的我，3岁便与Python结缘，5岁已深谙Java之道，满怀着成为数据库界璀璨新星的梦想翱翔。然而，命运弄人，我在那条路上遭遇了意想不到的挫折，未能如愿照亮天际。
三十年河东，三十年河西。
如今，在这一世，我终于得以弥补前世的遗憾，达成了心中的夙愿，实现了圆满。
但人生没有终点，只有更高的起点。在金仓数据库的每一天，我都在与一群志同道合的伙伴共同探索高性能数据库的奥秘，用代码给性能加速，用智慧为数据护航，不断挑战技术的极限。
话题互动
在评论区中分享
“假如你重生了，你最想做什么？”
留言点赞前10名
将获得电科金仓送出的定制帆布包1个！
活动截止
2024年11月8日晚18:00
快来参与吧！
