晚期物化：GBase 8a的“内存减负术”

明明只想查几列数据，数据库却把整行数据都拽进内存，结果内存爆了、查询慢了、并发没了。GBase 8a的“晚期物化”技术，专门解决这个问题。它用“行号”代替真实数据跑完所有中间计算，只在最后一步才把需要的列解压、拼装、加载。实测下来，内存占用能省几十到上百倍。本期内容就来拆解这套“拆包延迟”的黑科技。

传统物化：为什么内存总是不够用？

先解释一个概念：“物化”，就是把查询的中间结果变成实实在在的数据集。

传统数据库（包括普通列存）采用“早期物化”：查询时先把整行数据读出来、拼好，再执行过滤、聚合。比如一张表有100列，只想查5列，但系统先把100列全加载到内存，再把不需要的95列扔掉——内存浪费严重。
在OLAP大表分析场景中，这种浪费会被放大。几亿行数据，每行几百字节，还没开始算，内存先被撑爆了。

晚期物化：把“拆包”留到最后

GBase 8a的晚期物化，逻辑很简单：“全程用行号（Row ID）计算，只在最后一步才加载真实数据。”

整个流程分三步：

01 Smart Scan智能过滤

利用列存自带的智能索引，快速跳过不满足条件的数据块。索引维护自动化，用户不用管。

02 行号标记全程运算

在过滤、JOIN、聚合等所有中间操作中，只传递行号。行号只占几十字节，而整行数据可能几百甚至几千字节。这一步就把内存占用压到了极致。

03 晚期物化生成结果

等所有计算完成，确定最终结果集后，才去解压需要的列，拼接成完整行，返回给用户。

一句话总结：先干活，后打包。无关数据全程不沾内存。

效果实测：几十倍到上百倍的内存节省

假设一张1亿行的表，要查5列数据，最终结果集是100万行。

结果：内存占用从“几百MB甚至几GB”降到“几十MB”。实测中，大表聚合、多表大JOIN场景，内存从几十GB降到几百MB，下降几十到上百倍。

除了省内存，还能降CPU和I/O：只解压需要的列，只读取需要的数据，无效操作大幅减少。

怎么用？默认开启，参数可调

1. 默认自动启用 

针对列存表，GBase 8a默认开启晚期物化，不用人工配置。行存表、小表、临时表会自动跳过。

2. 两个核心参数

• gbase_parallel_threshold**（并行物化阈值） 

结果集行数超过该值时，启用并行物化（快但占内存）；否则串行物化（慢但省内存）。默认10000。  

• 内存紧张、高并发场景：调大到50000，多用串行物化，省内存。  

• 内存充足、追求速度：调小到1000，多用并行物化，提效率。

• gbase_result_threshold**（结果集上限）

防止结果集过大导致内存溢出。默认极大值（128TB），基本不限制。  

• 内存紧张时，可设为单节点最大表行数的2倍，或固定行数（如2亿），防止单个查询撑爆内存。
   

最佳实践：晚期物化+SQL优化，效果翻倍

1. 内存堆分配要合理

晚期物化的中间计算主要消耗“计算堆”（gbase_heap_large），这块内存要管够。推荐比例（基于物理内存）：

• 数据堆：60%

• 计算堆：24%

• 临时堆：8%

• 总内存上限：80%

2. SQL写法要“抠门”

• 禁止SELECT *：只查需要的列，否则多列拼接会抵消晚期物化优势。

• 过滤条件前置：WHERE子句越严格越好，提前筛掉无效数据。

• 大表先过滤再JOIN：关联前先缩小大表范围，避免全量数据参与运算。

• 避免大结果集排序：排序会把全量结果集加载到内存，尽量在物化后排序，或加LIMIT限制。

3. 高并发场景做好内存保护

• 控制并发会话数，避免多个查询叠加耗尽内存。

• 设置单个会话的算子内存上限。

• 用监控命令实时观察物化内存占用，及时调整异常查询。

实战效果

• 大表聚合（10亿+行）：内存占用下降70%-90%，查询速度提升30%以上。

• 多表大JOIN（3张亿级表）：中间结果内存从几十GB降到几百MB，查询从分钟级到秒级。

• 高并发报表：相同硬件，并发查询数提升2-5倍，报表延迟平均降低40%。

晚期物化的核心，就是“按需物化、精准控存”，用最小的代价跑完中间计算，只在最后一刻才打包数据。对于海量数据OLAP场景，这是GBase 8a区别于传统数据库的关键优势之一。