本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
只有当读取查询返回非常大量的顶点和边缘或 RDF 三元组的属性时，查找缓存才会有所帮助。
为了优化查询性能，Amazon Neptune 使用 R5d 实例类型为此类属性值或文本创建大型缓存。这样，从缓存中检索它们要比从集群存储卷中检索它们快得多。
根据经验，只有满足以下所有三个条件时，才值得启用查找缓存：
您会一直在观察到读取查询的延迟时间增加。
运行读取查询时，您还会发现
BufferCacheHitRatioCloudWatch 指标有所下降（请参阅使用亚马逊监控 Neptune CloudWatch）。在呈现结果之前，读取查询会花费大量时间来实体化返回值（有关确定要为查询实体化多少个属性值的方法，请参阅下面的 Gremlin-Profile 示例）。
注意
此特征仅在上述特定情况下有用。例如，查找缓存根本无助于聚合查询。除非您运行的查询会受益于查找缓存，否则没有理由使用 R5d 实例类型来代替等效且成本更低的 R5 实例类型。
如果您使用的是 Gremlin，则可以使用 Gremlin profile API 来评测查询的实体化成本。在“索引操作”下，它显示了在执行过程中实体化的项数量：
Index Operations Query execution: # of statement index ops: 3 # of unique statement index ops: 3 Duplication ratio: 1.0# of terms materialized: 5273Serialization: # of statement index ops: 200 # of unique statement index ops: 140 Duplication ratio: 1.43# of terms materialized: 32693
实体化的非数字项的数量与 Neptune 必须执行的项查找数量成正比。
