不是的. 最好给予Incremental crawl以足够的时间来结束每一次的incremental crawl.
Incremental Crawl也叫增量爬网, 如果增量爬网的频率越高, 新增的或新修改的内容就会能越早地在搜索功能中查找到. 可是, 增量爬网的时间却并不是越短越好的.
比如说配置增量爬网每5分钟运行一次, 而平均成功结束一次incremental crawl需要15分钟. 并且如果服务器场内有多台Query Server的话, 会在数据库端有dead lock的情况发生.
为什么这样会有dead lock呢?
因为SharePoint 有一个存储过程, 叫做“proc_MSS_PropagationQueryServerReportTaskReady”. Query Server们会调用它, 它专门负责告诉Index Server上一次的index propagation是否成功了. 在该存储过程中会有修改数据库表的动作, 所以就会有锁的动作发生. 当爬网非常频繁, 而索引服务器有比较多, 就会出现死锁.
注意, 这里的存储过程的设计是一种循环的调用, 一旦发现锁了, 那么就睡一小会儿, 待会儿再来尝试. 直到成功为止. 问题就出在旧的还没来得及结束, 更新一次的增量爬网又结束了, 又要来一次新的propergation. 于是问题不断的堆积, 最终导致爬网出现严重的问题.
极致的情况是, 表面上看上去是一次增量爬网, 但是实际上内部进行的是完全爬网. SharePoint会在死锁过多的情况下放弃增量爬网, 开启完全爬网. 所以, 增量爬网的时间间隔过短的另一个表象就是偶尔的某一次增量爬网需要的时间远远超过了平时的增量爬网的时间. 因为它在进行完全爬网.