<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>无索引邻接 on PlumePHP</title><link>https://plumephp.com/tags/%E6%97%A0%E7%B4%A2%E5%BC%95%E9%82%BB%E6%8E%A5/</link><description>Recent content in 无索引邻接 on PlumePHP</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Mon, 28 Sep 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://plumephp.com/tags/%E6%97%A0%E7%B4%A2%E5%BC%95%E9%82%BB%E6%8E%A5/index.xml" rel="self" type="application/rss+xml"/><item><title>图数据库存储引擎内部：无索引邻接、存储布局与遍历引擎</title><link>https://plumephp.com/graphdb-graph-database-internals/</link><pubDate>Mon, 28 Sep 2026 10:00:00 +0800</pubDate><guid>https://plumephp.com/graphdb-graph-database-internals/</guid><description>&lt;h2 id="引言"&gt;引言&lt;/h2&gt;
&lt;p&gt;图数据库的「快」不是魔法，而是存储与执行设计的直接结果。本文拆开图数据库的黑盒：先讲它最核心的武器——无索引邻接（index-free adjacency），为什么它让关系查询省掉 JOIN；再深入磁盘上的存储布局（节点、关系、属性的记录结构）与遍历引擎（从图到执行计划）；然后是索引与查找、属性存储与压缩、内存图与磁盘图的取舍、事务写入与 WAL、从 Cypher 到物理计划的查询流水线；最后对比 Neo4j / JanusGraph / NebulaGraph 的存储引擎设计。目标：你能解释「图查询为什么快、什么时候不快、瓶颈在哪」。&lt;/p&gt;</description></item></channel></rss>