如果想要使用a_b_c【该文本字段既索引又存储】这样的动态字段来返回一个用户友好的字段名fleldname，字段别名方法在这里就能发挥作用。只需在字段列表中指定fieldname:a_b_c就可以了。另外，可以对任何字段以任何名称重命名【特殊名称除外】。
三.搜索结果分页一个查询可能会匹配出大量文档，但是搜索结果通常以一页一页的方式显示给用户，每页包含一定数量的搜索结果。虽然Solr能够以毫秒级别对数百万或者数十亿文档进行高效地查询匹配，但它并没有对返回大量文档的处理方面进行优化。Solr返回数十个或数百个文档不在话下，但从千数量级开始，请求速度和吞吐速度会大幅降低。Solr的最佳实践是，首先只返回最相关的一页结果，然后允许用户继续获取后面的结果页面。这样做的话，Solr的每个请求都只返回有限数量的文档，避免了某个查询请求为了一次获取太多数据，占用资源并影响其他查询的执行速度的情况出现。
Solr的搜索结果分页需要使用两个请求参数：start和rows。start表示开始位置，从0开始。rows参数表示返回的文档数。例如：
搜索得到的结果按一定的次序返回。默认按关键词相关度得分进行排序，除此之外，日期、词项、数字以及函数等都可以作为排序依据。
1.按字段排序执行关键词搜索，搜索结果默认按照文档的相关度得分以降序方式进行排序。对于相同得分的文档，根据搜索索引的Lucene内部文档编号以升序方式进行排序。如果没有相关度得分，则按Lucene内部文档编号进行排序。通过sort参数可以轻松地在搜索请求中修改默认排序。例如：
字段排序的语法是由字段和排序方向组成的列表，字段与排序方向之间使用空格分隔，各组字段排序之间使用逗号分隔。排序字段必须在schema.xml中标记为indexed=true，排序方向分asc和desc两种。
注意，字段不同语言的排序也不尽相同，Solr内置了针对特定语言排序的分词过滤器。如果字段使用这些分词过滤器，搜索结果的排序可能符合该语言规则，但与标准字符串字段的排序有所不同。
需要注意一点，由于排序使用了索引词项，如果修改了索引词项，而非字段的原始值，那么排序结果可能对用户而言没有意义。如果在Solr中进行词项替换，那么 最终的索引值【而非发送到Solr的原始值】将是排序的键。
对缺失值排序还有一种特殊情况是，文档排序中sort字段缺少取值。由于Solr默认情况下不要求大多数字段都必备，因此很容易出现一个字段只有部分文档具备，在这种情况下，如果要对该字段进行排序，与查询相匹配但不包含该排序字段的文档应该出现在搜索结果列表中的前面还是后面？这个视情况而定，Solr提供了sortMissingLast和sortMissingFirst两个属性，用来选择合适的字段排序行为，这两个属性在schmea.xml中的定义如下：
solr 4.x及以前版本，设置麻烦且容易冲突
sortMissingLast属性设置为true，则不管排序方向如何，不包含该字段值的所有文档都会显示在搜索结果排序列表的末尾。sortMissingFirst与此类似。默认都为false。在默认设置下，缺少的文档会以升序显示在任何一种排序方式的开头，或以降序方式显示在任何一种排序方式的末尾。
solr 5.x及以后版本，默认为末尾。
排序的内存占用排序是一个非常占用内存的过程。为了对文档进行排序，Solr使用Lucene的字段缓存，在首次请求排序时将字段的所有唯一值加载到内存中，可能也存在其他原因导致缓存已经被加载。这意味着，要对包含数百万个唯一词项的索引进行排序，每个排序字段都会消耗大量内存。首次请求字段排序时需要构建内存结构，这可能导致初始排序查询变慢。这里不是说不应该对文档进行排序，而是意识到，排序需要有足够的内存来执行排序。此外，可能需要预热Solr实例来实现缓存加载。
2.按函数排序