开源版本：4.3.5.2
走obproxy执行一下select语句，第一次耗时约6秒，又多次执行，每次都在6秒左右。
按常规理解，服务器会缓存查询，下次执行时时间会缩短，而且sql中涉及的表，数据
确定是没有变更的。
请指教为何会这样，谢谢了！
你说的是结果集缓存吧，目前OB只能缓存执行计划以及内存中的行缓存和块缓存，没有结果集缓存
1 个赞
好像很少有数据库会主动做结果集缓存吧？大部分会做分析缓存、计划缓存、查询缓存。这个功能在并发下的效率很差的。我记得 MySQL 好像都移除了这个支持了。Oracle 默认也是关闭的。个人经验，蹲大佬~
对于这个认知不太认同
如果你这个SQL现状是最好最优的执行计划，本身就需要耗时6秒，符合预期，在条件没有变化的情况下，你凭啥叫他越跑越快呢？？那都这样的话，就不存在所谓的SQL优化了，大家都多跑几次就快了呗 
1 个赞
在执行计划不变的情况下，第一次执行慢，再次执行快，那证明他需要cache，cache也是有淘汰机制的，这就是传说中的冷启动问题。
估计第一次执行的时候 ，数据块本来就在KV cache里了。 数据库不是你所说的执行多次会越来越快的
2 个赞
重复查询不需要重新解析，不需要重新从磁盘里读数据块，但是各种执行计划里的步骤还是要做的
OceanBase数据库的存储引擎基于LSM Tree架构，将数据分为静态基线数据（放在 SSTable 中）和动态增量数据（放在 MemTable 中）两部分，其中 SSTable 是只读的，一旦生成就不再被修改，存储于磁盘，MemTable 支持读写，存储于内存。数据库 DML 操作插入、更新、删除等首先写入 MemTable，等到 MemTable 达到一定大小时转储到磁盘成为 SSTable。在进行查询时，需要分别对 SSTable 和 MemTable 进行查询，并将查询结果进行归并，返回给 SQL 层归并后的查询结果。同时在内存实现了 Block Cache 和 Row cache，来避免对基线数据的随机读。
Row Cache缓存具体的数据行，在进行Get/MultiGet查询时，可能会将对应查到的数据行放入Row Cache，这样在进行热点行的查询时，就可以极大地提升查询性能。