在 OB 的官方文档里面看到，OB 设计实现了多级缓存，针对不同的查询场景实现提速，其中 Rowcache 是整行数据，适用于 Get/MultiGet。我的疑问是：
MultiGet 的适用范围：
1）基于 PK，是否包括 between ... and ...、 in(... , ...) 以及 ...<= pk_id <=...
2）场景 1 下的 update 更新操作，是否同样适用于 Rowcache
文档中有关于一个 tenants 下的租户 cache 的调整，仅支持优先级。如果我的场景大部分都是点查，OB 是基于什么算法来判断和评估各个 cache 的大小的？以及通常情况下，各个 Cache 的占比分别是怎样的，最佳实践是什么？
第1个问题
between … and …: MultiGet 支持基于主键的 between … and … 查询。这种查询可以用来获取一个主键范围内的所有记录。
in(… , …): MultiGet 也支持基于主键的 in(… , …) 查询。这种查询可以用来获取多个特定主键对应的记录。
…<= pk_id <=…: 这种形式的查询也可以通过 MultiGet 来实现，因为它本质上也是基于主键范围的查询。
在使用 MultiGet 进行查询后，如果对这些记录进行 update 操作，这些更新操作同样会更新 Rowcache。Rowcache 是 OceanBase 中用于缓存热点数据的一种机制，确保频繁访问的数据能够快速响应。
当记录被更新时，Rowcache 中对应的缓存条目会被标记为无效或更新为最新的值，以保持数据的一致性。
综上所述，MultiGet 支持基于主键的 between … and …、in(… , …) 以及 …<= pk_id <=… 查询，并且在这些查询下的 update 更新操作同样适用于 Rowcache。
第2个问题：
OceanBase 数据库采用了多种缓存机制来提高查询性能，其中包括执行计划缓存（Plan Cache）、KVCache 缓存等。这些缓存机制旨在减少重复计算和磁盘 I/O，从而加快查询速度。
执行计划缓存（Plan Cache）: 当 SQL 请求第一次进入时，会进行硬解析并生成执行计划，然后将该计划缓存起来。后续相同的 SQL 请求可以直接使用缓存中的执行计划，从而节省解析时间。
内存配置: 在 OceanBase 中，可以通过配置参数来调整租户的内存分配，从而间接影响缓存的大小。例如，memory_limit_percentage 参数可以控制 OceanBase 数据库占系统总内存的比例，memstore_limit_percentage 参数可以控制 MemStore 占租户内存的比例。
KVCache 缓存: KVCache 缓存主要用于存储热点数据，以减少磁盘 I/O。虽然文档中没有明确提到 KVCache 缓存的具体大小调整方法，但可以通过调整租户的内存配置来间接影响 KVCache 的大小。
内存配置:可以适当调整 memory_limit_percentage 和 memstore_limit_percentage 参数，以确保租户有足够的内存来支持缓存。例如，可以将 memory_limit_percentage 设置为较高的值，以增加 OceanBase 数据库可用的内存量。
执行计划缓存: 对于主要执行点查询的场景，建议定期检查和优化执行计划缓存。如果发现某些 SQL 的执行计划不理想，可以手动绑定正确的执行计划。
监控和调优: 定期监控租户的内存使用情况，特别是缓存的使用情况。如果发现缓存命中率低或内存不足，可以适当增加租户的内存配置。
综上所述，通过合理配置内存参数和监控缓存使用情况，可以有效地优化 OceanBase 的缓存性能。对于主要执行点查询的场景，建议重点关注执行计划缓存的优化和内存配置的调整。
