Neo4j执行计划随返回Limit变化异常及优化问询

问题1：为何Limit超过阈值会出现笛卡尔积？ #

Neo4j的成本型查询规划器会依据数据库统计信息（比如关系数量、节点基数、属性分布等）估算不同执行计划的成本，选择它判定的最优方案。

• 当Limit较小时（比如100），规划器判断：先遍历ADDRESS_MATCH关系拿到企业对，再逐对检查是否共享令牌，凑够Limit数量就停止，这种嵌套循环+尽早限缩的策略成本最低，因此采用单分支执行计划。
• 当Limit调高到200-300的阈值时，规划器的成本估算逻辑发生变化：它认为继续用嵌套循环需要遍历的ADDRESS_MATCH企业对过多，总开销会上升；转而估算“先取出所有带令牌的企业-令牌关联，再和ADDRESS_MATCH企业对做笛卡尔积匹配”的成本更低。但实际数据中，这种笛卡尔积的实际开销远高于规划器的估算（比如令牌分布过于分散、ADDRESS_MATCH关系数统计不准），导致执行时间暴增。

另外，统计信息过时或不准确也会加剧这个问题——如果规划器拿到的节点/关系基数是旧数据，就会做出错误的成本判断。

问题2：能否强制采用Limit=100时的高效执行计划？ #

可以通过以下几种方式尝试：

1. 强制提前限缩结果集 #

用子查询先获取ADDRESS_MATCH企业对，再关联令牌，直接限定规划器的执行顺序：

MATCH (c1:Company)-[:ADDRESS_MATCH]-(c2:Company)
WITH c1, c2 LIMIT 300  # 先拿够300个地址匹配对
MATCH (c1)-[:CONTAINS_TOKEN]-(t:CompanyNameToken)-[:CONTAINS_TOKEN]-(c2)
RETURN c1, c2, t

这种写法会强制规划器先处理地址匹配，再检查令牌，不会触发笛卡尔积。

2. 使用规划器提示强制嵌套循环 #

Neo4j支持用USING NESTED LOOP JOIN提示，强制规划器采用嵌套循环而非笛卡尔积/哈希连接：

MATCH (c1:Company)-[:ADDRESS_MATCH]-(c2:Company)
MATCH (c1)-[:CONTAINS_TOKEN]-(t:CompanyNameToken)-[:CONTAINS_TOKEN]-(c2)
USING NESTED LOOP JOIN  # 强制用嵌套循环关联
RETURN c1, c2, t LIMIT 300

如果提示无效，可能是统计信息过时，需要更新统计信息：

CALL db.stats.generateSample()  # 生成最新的采样统计信息
CALL db.clearQueryCaches()     # 清除旧的执行计划缓存

3. 切换到规则型规划器 #

如果成本规划器的判断持续出错，可以临时切换到规则型规划器（它基于固定规则生成执行计划，不会依赖成本估算）：

CYPHER planner=rule
MATCH (c1:Company)-[:ADDRESS_MATCH]-(c2:Company)
MATCH (c1)-[:CONTAINS_TOKEN]-(t:CompanyNameToken)-[:CONTAINS_TOKEN]-(c2)
RETURN c1, c2, t LIMIT 300

问题3：为何EXISTS子查询的执行计划更稳定？ #

EXISTS子查询的语义是逐行检查：对每一对ADDRESS_MATCH的企业对，单独执行子查询判断是否存在共享令牌，一旦找到匹配的令牌就立即短路返回。

这种写法会强制规划器采用行驱动的嵌套循环策略，无论Limit多大，规划器都会认为这种逐行检查的成本低于全局笛卡尔积——因为EXISTS不需要遍历所有令牌关联，只要找到一个匹配就停止，实际开销可控。同时，EXISTS子查询的执行计划不会触发规划器的“集合型连接”（比如笛卡尔积）判断逻辑，所以执行计划始终稳定。

内容的提问来源于stack exchange，提问作者phantomias