【图数据库内核】图引擎全景：属性图作为一等公民的存储与遍历
内容提要
本文为图数据库内核系列首篇，介绍属性图引擎在存储生态中的角色，对比行存、LSM、向量引擎与GraphRAG。重点阐述Neo4j的record与block存储格式、邻接代价模型、页缓存及Cypher计划边界，并规划16篇阅读路线，强调原生邻接布局对多跳查询性能的关键作用。
延伸解读
存储布局决定多跳查询性能
文章指出，图引擎的性能故事几乎总是邻接局部性故事。不同存储布局（边表、CSR、原生指针链、block内联）在“取邻居”操作上的代价差异显著，尤其影响多跳查询。理解这些布局的权衡，有助于在实际选型时根据查询模式（点查密集还是分析型）做出更合理的选择。
版本迁移需关注弃用时间线
Neo4j的standard/high_limit格式自5.23弃用，支持窗口延伸至约2029-11，但下一LTS后无法启动遗留store。Enterprise用户应尽早迁移到block格式，Community默认aligned。运维需关注store字段，避免因版本升级导致数据不可用。
索引与遍历的边界
索引用于找到候选起点，遍历负责沿拓扑扩张，二者不能互相替代。常见事故是用属性索引取出超大起点集合再做变长路径，导致计划乘积爆炸。理解这一边界，有助于优化Cypher查询，避免性能陷阱。
Q&A
属性图数据库与关系数据库在存储和查询上的核心区别是什么？
属性图数据库将节点、关系和属性作为一等公民，存储时采用原生邻接布局，查询通过模式匹配和路径扩展（如Cypher）进行；而关系数据库以表和JOIN为核心，查询图数据需要多次JOIN或递归CTE，多跳查询性能较差。
Neo4j的block存储格式相比record格式有哪些优势？
block格式通过128字节主块内联节点和关系数据，减少指针追逐，提高数据局部性，从而减少页故障；record格式采用指针链，局部性受链长影响，随机读较多。block格式是Enterprise推荐格式，支持更高实体上限。
Neo4j中standard和high_limit存储格式的弃用时间线是怎样的？
standard和high_limit格式自5.23版本起弃用，计划在vNext.LTS（约2026-11）后仍支持一段时间，支持窗口延伸至约2029-11；high_limit在下一LTS之后将无法启动遗留store，企业用户应尽早迁移到block格式。
什么是超节点（dense node）？它对图查询性能有何影响？
超节点是拥有大量关系的节点，在Neo4j中会进入dense store，以多根B+树按类型和方向组织关系。超节点使缓存命中模型接近索引扫描而非指针追逐，但可能导致基数估计不准和遍历性能问题。
在Cypher查询中，索引和遍历分别扮演什么角色？
索引用于快速找到符合谓词的候选节点或边，作为起点；遍历则从候选出发沿拓扑扩展邻居。索引不能替代深度expand，若用索引取出超大起点集合再做变长路径，可能导致乘积爆炸。
图数据库的邻接代价模型有哪些常见布局？各有什么优缺点？
常见布局包括边表+索引、CSR/邻接数组、原生指针链和block内联。边表+索引适合SQL工具链但多跳重复探测；CSR只读分析快但更新贵；原生指针链点查便宜但指针追逐打碎局部性；block内联减少追逐但空节点占固定主块。
GraphRAG应用是否需要强一致的图数据库？
不一定。GraphRAG应用层通常需要检索编排和召回质量，对一致性要求不高，最终一致加向量即可；但对于审计、权限等边，需要事务支持。应根据边的语义分级，不一刀切。
