如主帖所述，数据浏览功能实际上也是一种检索功能。那么，假如在OPAC环境中构造出了针对数据库进行一种较宽泛的检索浏览命令，比如在全部书目库中，以前方一致查找分类号为"I"的数据，就有可能命中几十万条数据（比如在一个以文学作品为主要收藏对象的大图书馆中）。
任何系统，处理这类检索请求都会产生较长的响应时间和较大的数据通讯负担，甚至因为OPAC系统面向更多的访问者，如果多人并发进行这样的检索，系统负担就会极剧增加，这也是很多系统不得不限定检索结果甚至不允许宽泛的检索请求的原因。
为了更贴近用户需求，我们的数据浏览功能中，引入了“缓存机制”，从而实现“鱼肉与熊掌得兼”的效果。
所谓“缓存机制”，是指系统第一次得到检索请求后，它也会老老实实去响应检索请求，无捷径可寻。但是，系统会将此次的检索结果在响应访问者的同时，缓存到服务器中。这样，当下一个访问者提交同样的检索请求时，系统将会优先用服务器中的缓存响应访问者，从而实现响应效率的极大的提高、也无须增加数据库的查询负担。
这种缓存信息，仅是命中结果的记录ID，并不是全部的数据内容，所以无须产生系统服务器硬盘空间不足之虑。
虽然这种缓存机制，是通过牺牲数据更新实时性来换取响应效率性。但基于常见的数据更新频率（比如普通图书馆，一天新增的目录数据可能仅百来种），所以这种牺牲还是值得的。
除了在OPAC环境中，由第一个访问者点击浏览链接锚点来触发缓存的产生外，系统还允许在配置文件中，由用户根据本馆实情，定义这种缓存自动刷新的频次，参见主帖中介绍的build="autoUpdate=perhour"属性值。系统管理员可以定义为每小时或每天自动刷新缓存。理论上可以定义到每分钟进行刷新以接近数据实时更新效果，但这样做，实际意义与效果就不好了。
即便设置了自动刷新频次，如果遇到突发的需要缓存及时更新的情况，比如系统一次性添加了很多数据后。系统管理员也可以在OPAC环境中，以“馆员”身份登录后，进入各“浏览”环境，执行相关的“刷新”、“增补”缓存的操作——此操作，需要预先为相关馆员帐户添加管理缓存等权限。