sphinx kill-list設定

官方文檔：
*******************************************************************************************************************
11.1.16. sql_query_killlist：Kill-list查詢

用於得到Kill-list的查詢。可選選項，預設為空白（不設定查詢）。僅適用於SQL資料來源（mysql, pgsql, mssql）。版本0.9.9-rc1引入.
這個查詢返回的結果集應該只有一列，每行是一個文檔ID。返回的這些文檔ID將被儲存在一個索引裡。根據查詢中提到的索引的順序，一個索引的kill-list會抑制來自其他（順序在其前面）索引的結果。這個設計的目的是要協助使用者實現在現有索引上的刪除或者更新，而不用重建索引（甚至根本不用訪問這個索引），尤其是為了結果解決“幽靈結果”問題。
讓我們來分析一個實際的例子。假設我們有兩個索引，‘main’和‘delta’。假設文檔2、3和5在上一次重建索引‘main’的時候就被刪除了，而文檔7和文檔11則被更新了（即他們的文字內容發生了變化）。假設在建立索引‘main’的時候，關鍵字‘test’在所有這些提到的文檔中都出現了。而當我們建立索引‘delta’的時候文檔7中也出現了關鍵字‘test’，但是文檔11中不再有關鍵字‘test’了。現在我們重建立立索引‘delta’，然後以合適的順序（較舊的排在較新的之前）對這兩個索引進行檢索：
$res = $cl->Query ( "test", "main delta" );
首先，我們要正確地處理刪除的情況。結果集合不應該包含文檔2、3或5。其次，我們也要避免出現幽靈結果。如果我們不做點什麼，文檔11就會出現在搜尋結果中。因為它會被在‘main’中查到（但在‘delta’中查不到它），並出現在最終的結果集合中，除非我們做點什麼防止這種情況的發生。
Kill-list，或者縮寫成K-list就是我們要做的。附加在‘delta’索引上的Kill-list會屏蔽掉前面所有各索引中檢索到的特定行，在這個例子中，也就是‘main’中的行。因此，想要得到預期的結果，我們應該將更新了的和刪除了的文檔ID都放進Kill-list。
樣本：

sql_query_killlist = \
SELECT id FROM documents WHERE updated_ts>=@last_reindex UNION \
SELECT id FROM documents_deleted WHERE deleted_ts>=@last_reindex

*************************************************************************************************************

個人總結：
1.在delta index的源中要寫sql_query_killlist
2.indexer --merge main delta --merge-dst-range deleted 0 0 --merge-killlists --rotate重建索引，合并索引
3.查詢時一定要將舊的索引排在前面，在這裡就是main在前，delta在後：search -i main -i delta xxx（這樣後面delta中設定的sql_query_killlist才能起作用）

4.在用php的query介面時，也要注意給定的index的順序，old在前，new在後，如果是*的話，一定要保證conf中聲明的index順序是舊前新後

5.如果想要用kill-list，那麼一定不能只指定舊的main索引，因為sql_query_killlist並不是將關鍵字映射關係刪除，而只是屏蔽，如果只指main，相當於delta中的sql_query_killlist並沒有發揮作用，舊資料還是可以被查詢到；必須指定main
delta這樣的索引順序，才可以將delta中的sql_query_killlist效果產生在mian的結果集上。

6.--merge-killlists的作用只是產生一個ignore_list（if
id in ignore_list）ignore，如果只有main作為指定範圍，即使main的結果與delta的結果merge過,但是因為沒有ignore_list作為過濾條件，舊的記錄依然可以查詢到；-i main -i delta這樣才會將main的結果通過delta的ignore_list的過濾，因為在delta中設定了sql_query_killlist。

The
kill-list is basically a list of "ignore this ids".

It
does make sense. Is the delta index the last one specified in setup and query?
Otherwise it won't work.

Note that the kill list does not change the non-delta index, it simply provides a list of
ids that should be ignored on preceding indexes. Why do I say "preceding indexes"? Well,
consider this:

$cl->Query("some terms", "index1 index2withkilllist index3");

Any terms that would be excluded in the kill list will not affect index3 at all.

In your case, if the delta isn't the last index defined in the distributed index and
queried it'll fail.