nBINsFetchMiss=575,490The first step in tuning the JE cache, as related to performance, is to ensure that nBINsFetchMiss goes to zero. That tells you that you've sized your cache large enough to hold all internal nodes (I know you have lots of memory, but we need to prove that by looking at the stats).
I know you can avoid LN loading via setPartial(), however, it's unclear from the doc whether a call to cursor.getNext() with a setPartial(0, 0, true), then a subsequent call to cursor.getCurrent() to retrieve the LN causes the key to be re-read (I guess I could test that and eyeball the numbers).That's what I was going to suggest (using setPartial(true,0,0) for the data param), so you figured it out on your own. If you call getCurrent with a plain DatabaseEntry (no setPartial(true, 0, 0)) then it will return the data, so it has to read the LN (if it's not in cache).
The difference in my particular query pattern is that it's quite possible the ratio of cursor.getNext()'s vs actual data I want is only ~50%.Yes, but would be good to prove that with stats.
If it's possible to not read the key twice, this could be a much more efficient approach with my particular workload.The key will be returned by getCurrent but it is in cache and this just involves a byte array copy.
Any insight/opinions you might have as to whether that's a vaguely feasible approach would be very welcomeYes, it is. Also if you use setPartial(true, 0, 0) on the original data param, when calling getSearchKey, you can avoid reading an LN when there are no keys in the range. Of course if the first key found is in range, you'll have to call getCurrent to get the data.