明明只想查几列数据，数据库却把整行数据都拽进内存，结果内存爆了、查询慢了、并发没了。南大通用GBase 8a数据库（gbase database)的“晚期物化”技术，专门解决这个问题。它用“行号”代替真实数据跑完所有中间计算，只在最后一步才把需要的列解压、拼装、加载。实测下来，内存占用能省几十到上百倍。本期内容就来拆解这套“拆包延迟”的黑科技。
1、 传统物化： 为什么内存总是不够用？
先解释一个概念： “物化” ，就是把查询的中间结果变成实实在在的数据集。
传统数据库（包括普通列存）采用“早期物化”：查询时先把整行数据读出来、拼好，再执行过滤、聚合。比如一张表有100列，只想查5列，但系统先把100列全加载到内存，再把不需要的95列扔掉——内存浪费严重。
在OLAP大表分析场景中，这种浪费会被放大。几亿行数据，每行几百字节，还没开始算，内存先被撑爆了。
2、 晚期物化： 把“拆包”留到最后
GBase 8a的晚期物化，逻辑很简单：“全程用行号（Row ID）计算，只在最后一步才加载真实数据。”
整个流程分三步：
01、 Smart Scan智能过滤
利用列存自带的智能索引，快速跳过不满足条件的数据块。索引维护自动化，用户不用管。
02、 行号标记全程运算
在过滤、JOIN、聚合等所有中间操作中，只传递行号。行号只占几十字节，而整行数据可能几百甚至几千字节。这一步就把内存占用压到了极致。
03、 晚期物化生成结果
等所有计算完成，确定最终结果集后，才去解压需要的列，拼接成完整行，返回给用户。
一句话总结：先干活，后打包。无关数据全程不沾内存。
3、 效果实测： 几十倍到上百倍的内存节省
假设一张1亿行的表，要查5列数据，最终结果集是100万行。
结果：内存占用从“几百MB甚至几GB”降到“几十MB” 。实测中，大表聚合、多表大JOIN场景，内存从几十GB降到几百MB，下降几十到上百倍。
除了省内存，还能降CPU和I/O：只解压需要的列，只读取需要的数据，无效操作大幅减少。
