Solr 6中BM25算法fieldLength值计算异常问题求助

这问题我之前帮团队排查过类似的，结合Solr 6 + BM25的特性，大概率是批量索引时的字段长度统计逻辑出了问题，给你几个具体的排查和解决方向：

• 检查批量索引的提交与段合并策略
  Solr批量索引时，频繁的软提交（softCommit）或者不合理的段合并配置，会干扰Lucene底层的FieldInvertState统计逻辑——这正是BM25计算fieldLength的核心依赖。你可以先试试：

  1. 临时关闭批量索引过程中的软提交，改成批量完成后一次性执行硬提交；
  2. 调整solrconfig.xml里<updateHandler>的段合并参数，比如调大maxMergeDocs、降低mergeFactor，减少段合并的频率，避免统计值在合并时出现溢出或错误累加。

• 确认字段类型与相似度配置的正确性
  BM25的fieldLength依赖字段的norms信息，要是字段配置有误，批量索引时很容易出现统计异常：

  1. 检查schema.xml中title字段的类型，确保没有设置omitNorms="true"（这个属性会禁用norms存储，直接导致fieldLength计算错误）；
  2. 验证BM25相似度的配置是否正确，示例配置如下：

     <similarity class="solr.BM25SimilarityFactory">
       <str name="k1">1.2</str>
       <str name="b">0.75</str>
     </similarity>
     

• 排查批量索引的并发线程问题
  你看到的5.6493154E19是一个典型的数值溢出结果，大概率是高并发批量索引时，Lucene的字段统计计数器出现了线程安全问题。可以先降低客户端的并发提交线程数，改成单线程批量提交试试：如果单线程索引后fieldLength恢复正常，那就是并发导致的统计错误，需要调整并发策略或者升级Solr补丁（Solr 6的部分版本存在并发索引时的统计bug）。

• 修复现有异常数据的方法
  对于已经出现异常的文档，单条重新索引可以临时修复，但要彻底解决的话：

  1. 先排查并修正上面的配置问题；
  2. 执行一次全量硬提交+索引优化（http://your-solr-url/core/update?optimize=true&waitFlush=true），合并所有段并重置统计值；
  3. 重新执行全量批量索引，确保统计逻辑正常运行。

内容的提问来源于stack exchange，提问作者K.Ali