Solr's XML response format
status：始終為0。除非查詢發生錯誤，將返回錯誤碼
QTime: 查詢耗時。由于有內部緩存，所以兩個相同的查詢的QTime是相同的，但是查詢速度更快
numFound: 總共查詢到的結果數
start:查詢返回結果集的起始數
maxScore:查詢結果中所有數據的最高得分，如果查詢請求的fl請求參數沒有指定score,那么返回結果中doc中是不會有得分字段的
返回的結果中的每一個doc對應的就是一條查詢出來的數據，一一對應于索引中的document，數據類型使用solr中的基本數據類型呈現，如果是多值字段，則以排序的多個字段呈現，每個字段同樣是簡單類型。
result節點之后可能會有facet highlight等
Parsing the URLurl中的文本必須是utf-8編碼，
Request handlers在solrconfig.xml中配置，允許配置兩件事情1.配置默認的參數和一些不會改變的常量。2。注冊solr查詢組件，例如faceting highlighting等
建議在實際應用中針對每一種類型的查詢配置單獨的request handler，這樣做的好處是可以通過配置修改參數，并且對于查詢統計提供更好的粒度
qt="handler name";
<requestHandler name="bands" class="solr.SearchHandler">
<lst name="defaults">
<str name="echoParams">none</str>
<int name="rows">20</int>
</lst>
<lst name="appends">
<str name="fq">a_type:group</str>
</lst>
<lst name="invariants">
<str name="facet">false</str>
</lst>
</requestHandler>
1。defaults: 默認參數設置，請求時參數會覆蓋此值
2。appends:可以設置多次的參數。像fq,除了請求參數中指定的同時此值也會被設置。
3.invariants:此值是常量值，并且不會被覆蓋（此值用于安全目的).
4.first-components, components, last-components:注冊當前handler可能會用到的handler。默認情況下已經注冊了一些組件，例如faceting highlighting等。設置first-components和last-components會分別前置或追加到這個列表中，設置 components會完全覆蓋默認的列表設置。
Query parameters對于boolean類型的參數，真值可以是true,on,yes，假值可以為false,off,no.
Search criteria related parametersq: query的簡寫，指查詢字符串，查詢語法使用defType的設定
defType：默認是lucene,大多數情況下將會使用dismax 或edismax
dismax和edismax支持許多增強的功能，更少的語法限制可以防止用戶得到不希望的結果或者是不小心使用lucene語法時提示出錯。
fq：用戶查詢時過濾條件的范圍，類似于sql中的where，此參數不會影響得分(scoring),此參數可以重復。
qt：查詢類型。就是前邊提到的request handler,一種方法就是用/aaa來命名，然后就可以在url中用aaa?....來訪問
Result pagination related parameters
start：默認是0，返回結果集中的起始位置，如果此值大于結果集的總數，那么將不會返回任何document，但是solr也不認為這是一個錯誤
rows：默認是10，
Output related parameters
fl：返回的字段列表，值用，/ 或空格分格，使用*符號返回所有字段但是不包括score，要想返回此字段必須添加
sort：排序字段，例如r_name asc,score desc，默認是score desc,也可以用function進行排序
wt：返回的格式，在solrconfig.xml中定義，目前支持的有xml（默認的），json,phthon,php,phps,ruby,javabin,csv,xslt,velocity.
version：不是很有用。
Diagnostic related parameters
用于開發調試，
indent：boolean值，用于使輸出更容易閱讀。
debugQuery： 如果為true,那么接下來的查詢結果會有<lst name="debug">的調試信息，其中包括轉換的查詢字符串，score的計算，以及處理faceting所耗時 間，explainOther：如果想知道為什么某個document沒有被匹配，或者得分不高，那么可以設置此值來進行查詢，例如 id:"Release:12345",這樣debugQuery的輸出肯定會包含第一個匹配此查詢的結果。
echoHandler：如果為true，將輸出與solr request handler匹配的java 類名。
echoParams： 控制是否在response header中包含查詢參數，可以用來調試url編碼過的查詢字符串，none禁用，默認的request handler設置此屬性為explicit,可以使用all來包含所有request handler中的配置參數，除了url中的。
timeAllowed：用來指定查詢的最長時間，以毫秒為單位。
Query parsers and local-params
solr中默認的query parser是lucene,
Query syntax (the lucene query parser)
solr完整的查詢語法是實現的lucene query parser.
lucene不支持查詢所有文檔，solr使用*:*可以查詢所有文檔
mandatory(強制性）prohibited(禁止）和優化
mandatory：+aaa:只匹配包含aaa的
prohibited： -aaa：匹配所有的,但是除了包含aaa的
optional: aaa 可選的
如果查詢語句至少有一個mandatory，那么optional就是可選的，但是他有一個很有用的功能就是文檔得分，會匹配更多的（也就是說文檔中可以包含optional也可以沒有）
如果查詢語句沒有mandatory,那么至少要匹配一個optional（也就是說文檔中必須要包含optional）。
optional也可以指定一個確定的數或百分比來進行匹配或不匹配，這樣的話就必須用dismax的min-should-match功能。
solr4將不再使用這種方法
Boolean operators
AND OR NOT
如果沒有明確標記為prohibited，那么AND or && 兩邊的操作會被認為是mandatory，例如aaa AND bbb 等同于+aaa +bbb
同樣的，OR操作會被認為是optional的 NOT等同于prohibited
Sub-queries
(aaa AND bbb) OR (cccc || ddd )
Limitations of prohibited clauses is sub-queries
lucene 不支持純粹的否定查詢，例如-Smashing -Pumpkins。solr對lucene進行增強來支持這種查詢，但是僅僅只能在頂層查詢，看下面這個例子 Smashing (-Pumpkins),這個查詢是在問：那個document包含Smashing或者不包含pumpkins嗎？無論怎樣，這樣寫都不會有正確結果 的。正確的寫法應該是讓子表達式只包含否定語句，并且添加查詢所有的查詢“*:*"就像這樣Smashing (-Pumpkins *:*)，這個限制只能應用在edismax查詢中。
Field qualifier
member_name:aaa
+member_name:aaa +member_name:bbb 也可以用簡寫形式+member_name:(+aaa +bbb),圓括號代表的是子查詢，這個查詢的目標字段都是同一個。
Wildcard queries
要注意的幾點
1. 不要對包含通配符的查詢字符串應用文本分析，甚至是小寫，假如你想查找Sma開頭的單詞，并且索引中的字段類型包含小寫，那么就應該使用sma*而不能用 Sma*。這是SOLR-219中的一個缺點。此外，假如你要使用的字段是應用了文本分析的，那么smashing*是不會匹配到Smashing的，因 為文本分析會把Smash轉換為smash，因此，不要應用文本分析。
2.通配符查詢是很慢的，使用ReversedWildcardFilterFactory可以提高很多，最壞的情況是在單詞兩端應用*號。
3.起始通配符應用*號的話結果會返回錯誤，除非使用ReversedWildcardFilterFactory。
例子：sma* ,sma*ing, sma??*(至少后邊跟兩個或者更多)
每一個匹配項都會得到相同的score，不管他使用那種查詢模式。lucene以犧牲性能來支持多種score，不過得進行一些設置讓solr來完成
有一個問題只是一個*號會怎么樣呢？結果取決于schema文件中是否有任何一個字段類型，即使索引鏈中沒有應用一個ReversedWildcardFilterFactory,*號都會應用所有field，如果不是這樣，那么會得到一個”不支持前導通配符“的錯誤。
Fuzzy queries
例子: Smashing~
波浪號用于模糊查詢，可以通過修改相似度（0-1，默認0.5）來進行查詢如：Smashing~0.7
就像使用通配符查詢一樣，如果要使用模糊查詢就應該將查詢字符串轉為小寫。
Range queries
例如：a_type:2 AND a_begin_date:[1990-01-01T00:00:00.000Z TO 1999-02-02T22:59:59.999Z]
"[]"包含兩端的值，”{}“不包含兩端的值，solr3中，要么都包含，要么都不包含。solr4兩個都允許。
也可以使用a_duration:[3000 TO *] 此處"*"號的方式lucene是不支持的
范圍查詢也可用于文本字段（不常用），此時所應用的索引字段只能有一個term 例如:somefield:([B TO C] -C)
Date math
solr 擴展了lucene原始的查詢轉換器，使date應用范圍查詢時再加方便，就像數字計算一樣。另外還可以通過”NOW“(精確到毫秒級)來獲取當前時間， 其語法還提供了補充，如減法，四舍五入根據不同的粒度，如年，秒等。操作可以鏈接到一起，并且從左向右執行，不允許有空格。例
r_event_date:[* TO NOW-2YEAR]
因為NOW是精確到毫秒級的，所以如果只是想到天的話可以用”/"向下舍入（此符號只會向下舍入）
r_event_date:[* To NOW/DAY-2YEAR]
可選的單位有YEAR,MONTH,DAY,DATE(與DAY相同)，HOUR,MINUTE,SECOND,MILISECOND,MILIT(與MILISECOND相同)
DateMath 不只是用于查詢，同樣用于索引，用于索引時應該使用正確的精度，否則精確到毫秒級的話不僅占用更多的磁盤空間，而且也會降低查詢速度，常用的索引日期字段 是這樣的<field name="indexedAt" type="tdate" default="NOW/SECOND" />
Score boosting
通過添加乘數可以修改查詢字符串中的條文貢獻給最終得分的程度，這叫做增強，0到1之間的值減少得分，大于1的值增加得分，
例：a_member_name:Billy^2 OR Smashing 或者 +Billy Bob Corgan^0.7
Existence (and non-existence) queries
如果要查詢某個字段下的所有文檔可以這樣a_name:[* TO * ]
也可以查詢某個字段下沒有值的所有文檔，-a_name:[* TO *]
Escaping special characters
+ - && || ! () {} [] ^ '' ~ * ? : \ 要想使用這些字符的原意可以用"\" 例id:artist\:aaa 通過雙引號也可以實現同樣效果id:"artist:aaa"
如果使用solrj與solr交互，可以使用ClientUtils.escapeQueryChars()進行轉義
The Dismax query parser
dismax 是lucene的DisjunctionMaxQuery之后的名字,這個query parser對于scoring 有直接關系.
edismax中的e是extended的意思，這個parser是在solr3.1中增加的，他由dismax的演化而來。
Searching multiple fields
<str name="qf">a_name a_alias^0.7 a_member_name^0.4</str>如果想根據scoring排序，可以將scoring設大一點，這樣就會排在最上邊
關 于schema中定義的stop words的效果，如果qf指定的字段中其中一些字段使用stop words而別一些沒有使用，那么查詢stop words將不會返回任何結果。edismax把查詢字符串中的stop words認為都是可選的（也就是可有可無），除非查詢字符串中全部使用stop words，使用dismax 你可以確保查詢字段中的查詢分板鏈過濾出相同的stop words值。
Limited query syntax
edismax首先會把用戶的查詢使用lucene支持的所有語法進行轉換，進行兩次調整，如果轉換失敗，它接下來會跳到原始的dismax的語法規則。
or和and還有布爾運算可以用小寫形式，并且支持純否定子查詢。
如果使用dismax，對于terms,phrase它都會限制可以使用的語法,并且使用+和-（而不是AND,OR,&&,||）來對條文應用強制應用和禁止應用。
還有就是是否需要對相關查詢的有效性進行轉義。為了不觸發錯誤，除非使用edismax否則就必須編碼來處理某些突出的問題。
Min-should-match
lucene query parser有兩種操作，一是默認操作是or,也就是說只要有一個條文匹配就可以，另一個就是使用AND來使所有條文匹配。它不能使用+或-進行明確指 定。這是兩種極端的情況。dismax有一個方法叫min-should-mathc,它用來指定多少條文必須匹配，或者有多少個是禁止的。這個值可以設 置為百分比或確定的數值。在配置文件中可以通過查詢參數“mm"來設置。語法也比較簡單。
Basic rules
mm參數的四個基本語法如下：
1：3 必須匹配3個條文，其余的是可選的。
2：-2 2個條文是可選的，其余的是必須的。
3：66% 66%的條文是必須的，其余的是可選的。
4：-25% 25%的條文是可選的，其余的是必須的。
注 意：-是對必須的除以可選的的逆向取值，它在這兒的定義其實沒有否定多少的意思。雖然75%和-25%看起來一樣，但是在rounding的時候就不一樣 了，例如有五個查詢條文，第一個條文需要三次，第二個條文需要四次，這也就說明如果要進行rounding計算，那么就需要反轉標志再用100減去此值。
另外兩點：1.如果mm的值是一個確定的值n，但是查詢的條文數小于此值，那么n會減少到查詢結果中的條文總數。例如mm值為-5但是查詢中的條文一共只有2個，所以結果就是所有條文都是可選的。
2.記住一點,不管是lucene還是solr，在所有查詢中，必須有一個條文是匹配的，即使所有條文都是可選的，
Multiple rules
是 以空格分隔的一個串，例如number<basicmm ，意思是說如果條文的數量大于number, 那么就應用basicmm規則。（規則的從左向右升序排列的）。只有最右端的規則才會被計算，執行的規則肯定是滿足最大的條文總數。如果不滿足任何一個規 則，那么所有條文都是必須的。例如：
2<75% 9<-3 這個規則的意思是說，如果條文總數大于9，那么其中3個是可選的，其它的都是必須的。如果條文總數大于2，那么75%是必須的。其它情況（也就是條文總數只有1個或2個）那么所有條文都是必須的（這是默認）。
What to choose
Min-should-match的簡單配置是使所有terms都是可選的。它的效果相當于默認的Lucene query parser 的OR操作，默認是0%。反過來的另一種極端就是所有terms都是必須的，這個就相當于AND操作，就像100%。
注 意：你可能想讓所有terms都匹配，實事上這也是默認設置。但是如果有一個term沒有找到，那么不會返回任何結果。當你設置一些terms是可選的時 候，匹配的結果會以score排序，包含最多terms的結果會排在頂部。還有一方法就是在沒有返回結果的時候進行二次查詢，但是solr是不支持的，不 過可以通過客戶端很容易的實現。
A default search
dismax 查詢支持一個默認查詢。也就是用戶沒有指定q的時候。參數是q.alt。例如<str name="q.alt">*:*</str>。這個參數通常設置在solrconfig.xml文件的request handler中來查詢所有文檔。在faceting中會使用到這個設置。如果不想返回任何結果可以設置為-*:*;
Filtering
filter查詢不會影響scoring，不像用戶查詢。要添加一個filter，只要使用fq參數。使用filter可以改進執行效率，因為每一個filter查詢都會緩存在solr的filter cache中并且執行速度相當快。
solr 3.4通過本地參數cache來控制是否啟用緩存
Sorting
使用sort參數，默認是score desc。例：sort=a_type desc,score desc
進行排序字段的數值類型必須是single valued,indexed,并且是not-tokenized。
另外solr還支持function query ，它通常用來計算空間地理位置的距離，或現在與字段值的時間差等。例sort=sub(begin_time,end_time) desc