fix(database/gdb): Resolve the bug where AllAndCount and ScanAndCount use the same specified cache key when enabling caching features, resulting in both count and select using the same cache #4339
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
执行这段查询后

g.DumpJson(result)
的结果是[ { "COUNT(1)": 5 } ]
,但是正确结果应该是五条用户信息,查看源代码后发现先执行的count查询和后来select查询都是直接使用了VIP
这个缓存key,在redis中实际缓存key是SelectCache:VIP
,第二步查询select获得的是count查询的缓存,所以查询结果是错的。因此在AllAndCount
和ScanAndCount
中包含的count应该使用SelectCache:CountCache:VIP
这个缓存作为区分。仅仅只在这两种查询时使用前缀SelectCache:CountCache:
避免和其他单独查询使用的缓存产生冲突