本文汇总了存算分离 Data Cache 使用过程中的常见问题及处理方法。
Q1：为什么通过 du、ls 命令看到的 Data Cache 目录占用空间远大于实际数据量？
Data Cache 的磁盘占用空间反映的是历史最高水位，与当前实际缓存的数据量无关。例如，假设导入了 100 GB 数据，Compaction 后数据量增至 200 GB，随后 GC 后数据量降回 100 GB，Data Cache 的磁盘占用空间仍保持在最高水位 200 GB，而内部实际缓存数据量为 100 GB。
Q2：Data Cache 是否会自动淘汰？
不会主动触发淘汰。Data Cache 仅在达到磁盘使用上限（默认为磁盘容量的 80%）时才开始淘汰数据。淘汰过程并不会实际删除数据文件，只是将旧缓存的磁盘位置标记为可覆盖，后续新缓存写入时会覆盖旧数据。因此，即使发生淘汰，磁盘占用空间也不会下降，不影响实际使用。
Q3：为什么磁盘水位一直维持在配置的最高点，不下降？
参见 Q2。Data Cache 的淘汰机制不会实际删除数据，只是将旧缓存标记为可覆盖，因此磁盘占用空间不会下降，这是正常现象，不影响实际使用。
Q4：为什么 DROP TABLE 后，远程存储显示表文件已删除，但 Data Cache 实际存储的数据量没有下降？
DROP TABLE 操作不会触发 Data Cache 删除缓存数据。被删除表的缓存数据会随时间推移，通过 Data Cache 内部的 LRU 逻辑逐渐淘汰，不影响实际使用。
Q5：为什么配置了 80% 的磁盘容量，实际磁盘使用却达到了 90% 甚至更高？
Data Cache 本身的磁盘容量使用是精确的，不会超过配置的上限。磁盘实际使用超过 80% 可能由以下原因导致：
运行产生的日志文件。
CN 崩溃产生的 Core 文件。
主键表的持久化索引（存储于
${storage_root_path}/persist/目录下）。BE/CN/FE 实例混部共享同一块磁盘。
外部表缓存文件（存储于
${STARROCKS_HOME}/block_cache/目录下）。磁盘使用了 ext3 等少见文件系统导致的空间统计差异。
排查建议：通过调小 starlet_star_cache_disk_size_percent 参数来降低 Data Cache 可使用的磁盘容量上限。
Q6：为什么各节点之间的缓存占用差异很大？
由于单机缓存的天然特性，各节点间的缓存占用无法保证完全一致，这是正常现象，在不影响查询延迟的情况下可以接受。导致差异的常见因素包括：
各节点加入集群的时间先后不同。
各节点持有的 Tablet 数量不同。
不同 Tablet 内的数据量差异。
各节点的 Compaction 和 GC 进度不同。
个别节点曾发生 Crash 或 OOM 问题。