问题标签 [extensible-storage-engine]

我有一个应用程序处理存储在 ESENT 中的大量数据（100 GB+）。该表的架构是：12 字节JET_bitColumnFixed键和JET_coltypLongBinary值，典型大小约为 2 KiB。页面大小设置为 32 KiB。我不会更改外部 long 值的默认 1024 字节大小阈值，因此我认为这些值主要存储在外部。

我对提高冷缓存查找和检索性能很感兴趣，因为这些操作是分批进行的，并且密钥是预先知道的。据我了解，JetPrereadKeys () API 旨在提高这种情况下的性能，但事实证明，无论有没有这个调用，我都看不到实际行为有任何变化。

更多详情如下：

• 就我而言，JetPrereadKeys() 总是报告足够数量的预读密钥，等于我在调用 API 时提交的密钥数量。如文档中所述，提交的密钥已适当排序。

• 我尝试了同步和异步两种方法，其中异步方法是：将预读调用发送到线程池，同时继续在当前线程上查找和检索数据。

• 通过尝试JET_paramEnableViewCache和JET_paramEnableFileCache参数的所有可用组合，我尝试了 ESENT 的两种可用缓存模式，无论是使用 MMAP 还是专用页面缓存。

• 除了一个小例外，我无法看到记录的 I/O 操作在有和没有预读的情况下有什么区别。也就是说，我希望此操作会导致（最好是异步）获取 B 树的必要内部节点。但我唯一看到的是从 JetPrereadKeys() 本身的堆栈中偶尔出现的同步小读取。读取的大小很小，从某种意义上说，我认为它不可能预取所有需要的信息。

• 如果我调试 Windows Search 服务，我可以中断对 JetPrereadKeys() 的各种调用。因此，至少有一个真实世界的示例调用此 API，大概是出于某种原因。

• 我所有的实验都是在机器重启后进行的，以确保数据库页面缓存为空。

问题：

1. 在所描述的情况下，JetPrereadKeys() 的预期行为是什么？

2. 如果我使用这个 API，我是否应该期望看到不同的 I/O 模式和更好的性能？我应该期望看到数据的同步预读还是异步预读？

3. 是否有另一种方法可以通过以某种方式向 ESENT 暗示即将到来的批次来提高 I/O 性能？

我们的 Windows 应用程序使用可扩展存储引擎 (ESENT)。对 ESENT 读写一段时间后，出现这个错误：

我对 ESENT 不熟悉，似乎在 MSDN 上找不到这个错误的详细描述。这是什么意思？有什么方法可以查看在给定时间有多少表游标可用？

我有一个带有 2 列主索引的 5 列表。假设索引定义为 ( Col1, Col2)。

在以下代码段中，Api.TrySeek返回false，我不知道为什么：

但是，如果我使用SeekGrbit.SeekGE，它会返回true。有人可以解释为什么吗？不适用于通配符列，但可以吗？SeekEQSeekGE

在循环中，我仔细检查了所有条目是否都具有Col1 == colVal1，以排除它只是在 where 找到条目的可能性Col1 > colVal1。