positionIncrementGap

使用場景：multi-value field對應的phrase query場景

Suppose a document has a multi-valued “author” field. Like this:

author: John Doe
author: Bob Smith

With a position increment gap of 0, a phrase query of “doe bob” would
be a match. But often it is undesirable for that kind of match across
different field values. A position increment gap controls the virtual
space between the last token of one field instance and the first token
of the next instance. With a gap of 100, this prevents phrase queries
(even with a modest slop factor) from matching across instances.

我們當前的搜尋場景不太需要phrase query的支援

precisionStep

使用場景：NumericRangeQuery，例如weight:[150 TO 600]

數值型別（int float double）在Lucene裡都是以string形式儲存的，當然這個string是經過編碼的

經過編碼後的string是保序的，也就是說num1>num2，那麼strNum1>strNum2

precisionStep用來分解編碼後的string，例如有一個precisionStep，預設是4，也就是隔4位索引一個字首，比如0100,0011,0001,1010會被分成下列的二進位制位“0100,0011,0001,1010“，”0100,0011,0001“，0100,0011“，”0100“。precisionStep這個值越大，那麼索引樹就越小，那麼範圍查詢的效能（尤其是細粒度的範圍查詢）也越差；precisionStep這個值越小，索引樹就越深，那麼查詢效能會提升，但是對應的空間複雜度就高了，一張圖說明一切：

precisionStep大，就對應沒有42，44，52，63，64那行，所以需要遍歷的值就較多,效率較低

precisionStep小，就對應右側如圖，需要遍歷的值只有423，641和642，其他的值在中間一層就都被找出來了，效率就高，相當於空間換時間

docValues

正排，多用於排序、facet、group以及自定義的精排和重排

omitNorms

在打分階段排除文件長度的影響，正常的TF-IDF打分邏輯是同樣命中一個term，如果文件A的term數量比文件B多，那麼A的分數就比B低，在很多場景下需要剔除文件長度對打分的影響

sortMissingFirst

true:在sort時如果某個doc的這個field是空的，那麼就優先出(first)
false:排序時當一個普通的空字串進行處理

sortMissingLast

同上，只不過是空值排最後