我在具有查找操作的数据流中看到了奇怪的行为。如果我选择“完全缓存”模式，则某些部分的查找会失败，我无法解释原因。“无缓存”和“部分缓存”一样正常工作。在这一点上，如果它神秘地失败，我不能相信生产中的“完整缓存”。
预期的结果是这样的——
1 808 larry curly moe
2 808 larry curly moe
3 314 foo bar baz
4 314 foo bar baz
5 314 foo bar baz
6 314 foo bar baz
完全缓存会产生这个 -
1 808 larry curly moe
2 808 larry curly moe
3 314 foo bar baz
4 314 foo bar baz
5 314 null null null
6 314 null null null
'314' 示例是实际结果。前两条记录正确查找，后两条失败。如果它们是缓存未命中，则它们应该对所有四行都失败。
失败是可重复的——相同的项目每次运行都以相同的顺序失败。该环境是一个隔离的测试环境，具有三个在运行之间不会发生变化的固定数据库。选择部分缓存明显变慢，这意味着有大量缓存未命中。没有一张表特别大，一千行左右。
这是怎么回事？我应该放弃使用完整缓存的希望吗？
我也看到过这种行为。我的原因是服务器内存，我将在指南中解释。这很烦人，因为它是断断续续的。
使用部分缓存，缓存开始为空，然后查询，直到找到匹配项。如果您有多个匹配项，则第一个获胜。使用完整缓存，如果您有多个匹配项，我不确定哪个会赢。可能是缓存顺序中的第一个。
部分缓存有一个未命中缓存的选项，它会记住哪些记录没有匹配，并且不会再次查询它们。如果您要插入正在查找的表中，这将是一个问题。同样使用完整缓存，如果您的源包含重复项，则插入第一个后第二个将无法匹配，如果您想抑制除第一个之外的所有内容，这将是一个问题。
以下是我在使用查找时尝试遵循的一些准则：
这让人头疼，但总比凌晨 3 点接到电话要好，因为一级客户 ETL 失败了。