【图数据库内核】生产排障：超节点、爆炸路径、内存三分与慢查询清单
内容提要
本文介绍Neo4j图数据库生产环境排障方法，核心是“三轴分流”：先判断慢查询属于计划基数（轴A）、存储I/O（轴B）还是锁/并发（轴C），再对症处理。文章强调超节点问题应优先优化建模与查询而非硬件，并给出内存三分（page cache、heap、OS）的配置与指标解读，以及锁死锁排查、慢查询固定流程和症状速查表。
延伸解读
排障先分轴，避免盲目调优
文章强调生产排障第一步是互斥假设，先判断慢查询属于计划基数（轴A）、存储I/O（轴B）还是锁/并发（轴C），而不是同时调整多个配置。这种分层方法有助于快速定位问题根源，避免因同时修改多处而无法归因。例如，若PROFILE显示Rows数量级爆炸，应优先检查查询计划而非增加内存。
超节点问题：建模优先于硬件
对于超节点（如门户点），文章建议优先优化建模和查询，例如收窄类型、加界变长、拆点等，而不是直接扩展硬件。引擎的dense优化只是缓解措施，不能免除建模责任。只有当工作集明确超出page cache且业务必须扫全邻接时，才考虑扩大缓存。
内存三分：page cache、heap与OS
内存配置需区分page cache、JVM heap和OS（含Lucene/向量）三部分。page cache主要影响I/O性能，heap影响算子状态和事务对象，而Lucene/向量占用OS页缓存。监控指标如hit_ratio和usage_ratio有助于判断瓶颈。若事务内存限制触顶，应先检查行流物化，再考虑增加堆。
锁与死锁排查要点
锁等待常表现为查询挂起但CPU占用低。使用SHOW TRANSACTIONS和dbms.listActiveLocks可区分慢计划与等锁。固定多实体更新顺序、审查乱序MERGE可减少死锁。注意读已提交隔离级别下，遍历结果可能被并发改写，这不一定是bug。
Q&A
Neo4j生产环境慢查询排查的第一步应该做什么？
第一步是进行三轴分流，即判断慢查询属于计划基数（轴A）、存储I/O（轴B）还是锁/并发（轴C），而不是一上来就加内存或改配置。
遇到超节点（dense节点）导致的性能问题，应该优先采取什么措施？
应优先优化建模与查询，例如收窄类型与方向、加界变长、拆点或边类型细分，而不是直接扩硬件。dense优化只是引擎缓解，不能免除建模责任。
Neo4j内存三分指的是哪三部分？各自的作用是什么？
内存三分指page cache、heap和OS内存。page cache用于缓存store和native索引页，heap用于算子状态和事务对象，OS内存用于Lucene全文/向量索引等。
如何区分慢查询是计划基数问题还是存储I/O问题？
通过PROFILE观察Rows是否数量级跳变，若Rows爆炸则偏向轴A（计划基数）；若Rows正常但hit_ratio低或DB Hits高，则偏向轴B（存储I/O）。
Neo4j中如何排查锁等待或死锁问题？
使用SHOW TRANSACTIONS和dbms.listActiveLocks查看锁信息，区分慢计划与等锁；对于死锁，可有限重试，并固定多实体更新顺序，审查乱序MERGE。
Neo4j慢查询排查的固定流程是什么？
流程包括：确认范围、查query log、EXPLAIN、PROFILE（短窗口）、对号入座、看内存分账、看指标时段、改一处复测一处。
事务内存限制触顶时应该怎么办？
先看行流物化（轴A），考虑优化查询减少物化，再考虑加堆。若怀疑误杀，可在受控环境临时关闭限制验证真实堆占用，但生产不建议长期关闭。
其他图数据库（如JanusGraph、TigerGraph）排障时能否直接套用Neo4j的指标？
不能，需要同构翻译，不要照抄Neo4j指标名。例如page cache miss对应JanusGraph的远端行读延迟，Rows爆炸对应Gremlin步产出爆炸等。
