0. 亲，低级错误知多少
"" 写成了“”
true 写成了 ture
false写成了fasel
String 写成了 string
userId 写成了userid
user_id 写成了 user_Id
userId 写成了 user_Id
1. <uniqueKey>id</uniqueKey>
这个uniquekey 作用：当add doc的时候，配置了uniqueKey，后面的doc中uniqueKey相同的会覆盖之前的doc， 如果没有配置，那么将不会覆盖。update的时候，依据uniqueryKey信息的话， 所以有update还是建议配上uniqueKey，一来比较完整配置信息，二来数据排查也方便。 对应id这个域，必须 stored=true、indexed=true，类型建议使用long或者int，而不是string 如果有特殊场景需要按id排序的，就的使用TriedLongField，否则排序时候会按文本序排序。
2. <defaultSearchField>title</defaultSearchField>
故名思议就是默认查询的时候，查什么域。这句的用法体现在： queryStr= content:abc 123, 等价 queryStr= content:abc title:123 queryStr= 123 等价 queryStr= title:123 也就是说等查询的时候，没有指定查那个域，默认就对应defaultSearchField了。 既然是defaultSearchField，那么这个域indexed=true 是必须的 注意区分 content:abc 123 与content:"abc 123" 以及 content:(abc 123)
3. 所有int sint tint long slong tlong float sfloat tfloat double sdouble tdouble
都不支持分词，也无需分词。没有sshort tshort，只有short。因为这些基本类型就一个值，无需什么分词。 对与int long fload Field，不应该出现positionincrmentGap=100 对与tint tlong tdoube 才有 pricisionStep、positionIncrementGap、sortMissingLast="true"属性。
4. 配置分词
所有TextField才有机会分词 所有TextField才有机会执行facet 所有TextField 配置的omitTermFreqAndPositions="true" 才会起效果，排序中频率位置信息没了
5. omitNorms="true" 这个参数影响域的得分，去掉之后，使得长短域相同词得分一致。按照香浓原理，
某个词出现在更长的文本中，或者出现次数越多，信息值更低。对应如果omitNorms=false，那么 下面 淘宝 出现doc1 淘宝杭州 出现doc2 淘宝杭州网络有限公司，命中淘宝的时候，doc1 得分高于doc2 注意：只有有一个域的omitNorms="false",等价所有域都保留了omitNorms 这个位置，尽管omitNorms内容是空， 所有，omitNorms在所有域都omitNorms=“true”的时候，才对索引有帮助。
6. required="true"
这个属性是说，一旦scham中该域启用required=“true”,那么建索引的时候，这个域时不能为空的，这个doc认为不完 整。当前走dump中心，会对null的赋值为"",也就不会出现没有值的情况。但是schema中还是应该突出下，如果逻辑上 有需要确保某些字段必须有
7. multiValued="true"
这个配置不是说某个域中term是单一or 多个的意义。即使mulitValued=false，一个text域同时可以是很长的 一段文本，也就是很多term的情况。multiValued="true"真正含义是：在传入doc建索引的时候，当一个域 是mulitValued="true"，那么可以向该域继续add内容。等价在一个doc中，相同域名的key:value 可以有 多个。通常情况下，使用map，key也就唯一了，不会出现多个相同key，不同value的情况。 另外，配置了mulitValued="true"，在命中返回文档的时候，返回的是list，而不是单个对象。 在终搜目前的建索引集中下，这个multiValued 配与不配已经没有任何作用影响dump过程，只是在命中返回的时候 返回的是list or 单个对象。 深入提示，multiValued="true" 在建索引的时候，实际上开辟了一个新的域，允许域名相同的域多次出现。 查询的时候会查询所有域名相同的域，这样导致检索性能会有一定影响，特别是域名膨胀之后，影响非常明显。
8.特殊分词
对应提出# ； ： 等分词，其实建议统一转化为空格分词，这是系统原生的分词，并且是基于编译器层的分词，性能更好。 没有必要为了一个#，重新定制一份代码，部署起来。
9. 排序、区间、一般查询
排序的应该是数字类型，建议使用trie类型，老的sortable 也是支持的 区间的也应该是数字类型的，建议使用tried类型 一般查询的多个数字组合的话，建议将数字字符化，然后空格分开，目前不支持数字类型的数组
10. date tdate等类型
在配置data tdate等类型的时候，需要注意时间格式。 另外，不推荐直接保存，而是保存差值后的int类型等。 由于data精度控制不同，将使得所用data域的term成线性增长，这是相当恐怕的事情。 这个长尾将消耗非常大的内存、空间资源。 在索引中term线性的增长是相当恐怖的事情。对长尾的处理目前还没有特殊优化。 通用在索引中term聚集性的增长也是相当恐怖的事情，对长链处理目前也没有特殊优化。
11.高级活
自我校验schema质量。 当schema配置完毕了，可以采取terminatorquickstart 测试一下，然后luke工具查看下索引结构。 这样可能会发现一些问题。可能很多地方的结构可以尝试优化。
12 重要参考信息
http://lucidworks.lucidimagination.com/display/solr/Solr+Field+Types
