问题现象
MemTable 已经转储成功，但是释放慢。在列存合并完成后，MemTable 才被释放。
关键诊断信息
触发条件
列存合并执行时间长 + 列存合并持有带数据的 MemTable。
事前巡检
无。
事后诊断
MemTable 长时间未释放，报错 It cost too much time to dec ref cnt，并且 MemTable 的释放时间和转储完成的时间间隔比较长。
在 MemTable 释放时间点前，有这个分区的列存合并完成，那可能是本问题导致。
问题原因
合并执行以分区为单位，合并过程中会持有这个分区 LSM-Tree 上所有 table（SSTable + MemTable）的引用计数，这样才能保证合并所有输入数据的有效性。合并完成后，才会释放 table 的引用计数。即使 MemTable 转储成功，也需要等待引用计数减为 0 才能被释放销毁。
当合并开始时，会预估本次合并的执行时间，如果合并涉及的数据量大，对应的完成时间预计较长，那么会尝试遍历所持有的 table 数组，进行特殊处理：只持有 SSTable 的引用计数，而不持有 MemTable 的引用计数，以此减少对 MemTable 释放的影响。但是这个步骤涉及 table 元数据管理等逻辑，会消耗一些时间，所以并不在合并的标准流程里，而是作为一个特殊路径，仅在合并涉及数据量大的场景下执行。
列存表的合并会为每个 CG 都生成一个 Major SSTable，当列存表的列数比较多时，会拆成多个任务执行，当所有任务都完成后，分区合并才算完成。但是每个任务作为一个独立的调度单元，可能由于任务调度等原因，列存表部分任务会在任务队列中等待，导致列存表的整体耗时比较长。而对于数据量比较少的分区，也不会走到 2）步骤里的特殊路径，所以导致合并长时间持有 MemTable 的引用计数，从而影响 MemTable 的释放。
问题的风险及影响
内存释放慢。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
影响版本
OceanBase 数据库企业版 V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本。
解决方法及规避方式
解决方法：
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.3.3 BP1 Hotfix4（oceanbase-4.3.3.1-101040032024123011）及之后版本、V4.3.3 BP1 Hotfix5（oceanbase-4.3.3.1-101050022025011419）、V4.3.3 BP1 Hotfix6（oceanbase-4.3.3.1-101060012025012322）、V4.3.3 BP1 Hotfix7（oceanbase-4.3.3.1-101070012025021915）。
加内存、重启。
规避方式：
无。
