SELECT  ... FROM ...  [LIMIT [offset,] row_count]
SELECT  ... FROM ...  [LIMIT row_count][ OFFSET offset]

{
  "table": "<table_name>",
  "query": ...
  ...
  "limit": 20,
  "offset": 0
}
{
  "table": "<table_name>",
  "query": ...
  ...
  "size": 20,
  "from": 0
}

SELECT  ... FROM ...   OPTION max_matches=<value>

{
  "table": "<table_name>",
  "query": ...
  ...
  "max_matches":<value>
  }
}

滚动搜索选项提供了一种高效且可靠的方式来分页浏览大型结果集。与传统的基于偏移量的分页不同，滚动搜索在深度分页时性能更好，并且实现分页更简单。 虽然它使用与基于偏移量分页相同的 max_matches 窗口，但滚动搜索可以通过使用滚动令牌在多次请求中检索结果，返回超过 max_matches 值的文档。 使用滚动分页时，无需同时使用 offset 和 limit —— 这是多余的，通常被认为是过度设计。只需指定 limit 和 scroll 令牌即可获取每个后续页面。

SELECT ... ORDER BY [... ,] id {ASC|DESC};

SELECT weight(), id FROM test WHERE match('hello') ORDER BY weight() desc, id asc limit 2;

+----------+------+
| weight() | id   |
+----------+------+
|     1281 |    1 |
|     1281 |    2 |
+----------+------+
2 rows in set (0.00 sec)

SHOW SCROLL;

| scroll_token                       |
|------------------------------------|
| <base64 encoded scroll token>      |

SHOW SCROLL;

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| scroll_token                                                                                                                                                                                                             |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| eyJvcmRlcl9ieV9zdHIiOiJ3ZWlnaHQoKSBkZXNjLCBpZCBhc2MiLCJvcmRlcl9ieSI6W3siYXR0ciI6IndlaWdodCgpIiwiZGVzYyI6dHJ1ZSwidmFsdWUiOjEyODEsInR5cGUiOiJpbnQifSx7ImF0dHIiOiJpZCIsImRlc2MiOmZhbHNlLCJ2YWx1ZSI6MiwidHlwZSI6ImludCJ9XX0= |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

SELECT ... [ORDER BY [... ,] id {ASC|DESC}] OPTION scroll='<base64 encoded scroll token>'[, ...];

SELECT weight(), id FROM test WHERE match('hello') limit 2
OPTION scroll='eyJvcmRlcl9ieV9zdHIiOiJ3ZWlnaHQoKSBkZXNjLCBpZCBhc2MiLCJvcmRlcl9ieSI6W3siYXR0ciI6IndlaWdodCgpIiwiZGVzYyI6dHJ1ZSwidmFsdWUiOjEyODEsInR5cGUiOiJpbnQifSx7ImF0dHIiOiJpZCIsImRlc2MiOmZhbHNlLCJ2YWx1ZSI6MiwidHlwZSI6ImludCJ9XX0=';

+----------+------+
| weight() | id   |
+----------+------+
|     1281 |    3 |
|     1281 |    4 |
+----------+------+
2 rows in set (0.00 sec)

POST /search
{
  "table": "<table_names>",
  "options": {
      "scroll": true
  },
  ...
  "sort": [
    ...
    { "id":{ "order":"{asc|desc}"} }
  ]
}

{
    "timed_out": false,
    "hits": {
        ...
    },
    "scroll": "<base64 encoded scroll token>"
}

POST /search
{
  "table": "test",
  "options":
  {
    "scroll": true
  },
  "query":
  {
    "query_string":"hello"
  },
  "sort":
  [
    { "_score":{ "order":"desc"} },
    { "id":{ "order":"asc"} }
  ],
  "track_scores": true,
  "limit":2
}

{
  "took": 0,
  "timed_out": false,
  "hits":
  {
    "total": 10,
    "total_relation": "eq",
    "hits":
    [
      {
        "_id": 1,
        "_score": 1281,
        "_source":
        {
          "title": "hello world1"
        }
      },
      {
        "_id": 2,
        "_score": 1281,
        "_source":
        {
          "title": "hello world2"
        }
      }
    ]
  },
  "scroll": "eyJvcmRlcl9ieV9zdHIiOiJAd2VpZ2h0IGRlc2MsIGlkIGFzYyIsIm9yZGVyX2J5IjpbeyJhdHRyIjoid2VpZ2h0KCkiLCJkZXNjIjp0cnVlLCJ2YWx1ZSI6MTI4MSwidHlwZSI6ImludCJ9LHsiYXR0ciI6ImlkIiwiZGVzYyI6ZmFsc2UsInZhbHVlIjoyLCJ0eXBlIjoiaW50In1dfQ=="
}

POST /search
{
  "table": "<table_names>",
  "options": {
    "scroll": "<base64 encoded scroll token>"
  },
  ...
}

POST /search
{
  "table": "test",
  "options":
  {
    "scroll": "eyJvcmRlcl9ieV9zdHIiOiJAd2VpZ2h0IGRlc2MsIGlkIGFzYyIsIm9yZGVyX2J5IjpbeyJhdHRyIjoid2VpZ2h0KCkiLCJkZXNjIjp0cnVlLCJ2YWx1ZSI6MTI4MSwidHlwZSI6ImludCJ9LHsiYXR0ciI6ImlkIiwiZGVzYyI6ZmFsc2UsInZhbHVlIjoyLCJ0eXBlIjoiaW50In1dfQ=="
  },
  "query":
  {
    "query_string":"hello"
  },
  "track_scores": true,
  "limit":2
}

{
  "took": 0,
  "timed_out": false,
  "hits":
  {
    "total": 8,
    "total_relation": "eq",
    "hits":
   [
      {
        "_id": 3,
        "_score": 1281,
        "_source":
        {
          "title": "hello world3"
        }
      },
      {
        "_id": 4,
        "_score": 1281,
        "_source":
        {
          "title": "hello world4"
        }
      }
    ]
  },
  "scroll": "eyJvcmRlcl9ieV9zdHIiOiJAd2VpZ2h0IGRlc2MsIGlkIGFzYyIsIm9yZGVyX2J5IjpbeyJhdHRyIjoid2VpZ2h0KCkiLCJkZXNjIjp0cnVlLCJ2YWx1ZSI6MTI4MSwidHlwZSI6ImludCJ9LHsiYXR0ciI6ImlkIiwiZGVzYyI6ZmFsc2UsInZhbHVlIjo0LCJ0eXBlIjoiaW50In1dfQ=="
}

Manticore 设计为通过其分布式搜索功能实现有效扩展。分布式搜索有助于提高查询延迟（即搜索时间）和吞吐量（即最大查询数/秒），适用于多服务器、多CPU或多核环境。这对于需要搜索海量数据（即数十亿条记录和数TB文本）的应用至关重要。

其主要理念是将被搜索的数据水平分区到多个搜索节点，并行处理。

分区是手动完成的。设置步骤如下：

• 在不同服务器上设置多个 Manticore 实例
• 将数据集的不同部分分配给不同实例
• 在某些 searchd 实例上配置特殊的分布式表
• 将查询路由到分布式表

这种类型的表仅包含对其他本地和远程表的引用，因此不能直接重新索引。相反，应重新索引它所引用的表。

当 Manticore 收到针对分布式表的查询时，会执行以下步骤：

1. 连接到配置的远程代理
2. 向它们发送查询
3. 同时搜索配置的本地表（远程代理搜索的同时）
4. 从远程代理检索搜索结果
5. 合并所有结果，去除重复项
6. 将合并后的结果发送给客户端

从应用程序的角度来看，通过常规表或分布式表搜索没有区别。换句话说，分布式表对应用程序完全透明，无法判断查询的表是分布式还是本地。

了解更多关于远程节点的信息。

多查询，或称查询批处理，允许您在一次网络请求中向 Manticore 发送多个搜索查询。

👍 为什么使用多查询？

主要原因是性能。通过批量发送请求给 Manticore，而不是逐个发送，您可以通过减少网络往返时间来节省时间。此外，批量发送查询允许 Manticore 执行某些内部优化。如果无法应用批量优化，查询将被单独处理。

⛔ 何时不使用多查询？

多查询要求批处理中的所有搜索查询相互独立，但情况并非总是如此。有时查询 B 依赖于查询 A 的结果，这意味着查询 B 只能在执行查询 A 后设置。例如，您可能只想在主表中未找到结果时显示来自辅助索引的结果，或者您可能想根据第一个结果集中的匹配数指定第二个结果集的偏移量。在这些情况下，您需要使用单独的查询（或单独的批处理）。

SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price DESC; SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price ASC

需要注意两种主要优化：公共查询优化和公共子树优化。

公共查询优化 意味着 searchd 会识别批处理中所有仅排序和分组设置不同的查询，并且只执行一次搜索。例如，如果一个批处理包含 3 个查询，它们都是针对“ipod nano”的，但第一个查询请求按价格排序的前 10 个结果，第二个查询按供应商 ID 分组并请求按评分排序的前 5 个供应商，第三个查询请求最大价格，则全文搜索“ipod nano”只会执行一次，其结果将被重用以构建 3 个不同的结果集。

分面搜索 是特别受益于此优化的一个重要案例。实际上，分面搜索可以通过运行多个查询来实现，一个用于检索搜索结果本身，其他几个使用相同的全文查询但不同的分组设置来检索所有所需的结果组（前 3 名作者，前 5 名供应商等）。只要全文查询和过滤设置保持不变，公共查询优化就会触发，并大大提高性能。

公共子树优化 更加有趣。它允许 searchd 利用批量全文查询之间的相似性。它识别所有查询中的公共全文查询部分（子树）并在查询之间缓存它们。例如，考虑以下查询批处理：

donald trump president
donald trump barack obama john mccain
donald trump speech

有一个公共的两词部分 donald trump，只需计算一次，然后缓存并在查询间共享。公共子树优化正是这样做的。每个查询的缓存大小由 subtree_docs_cache 和 subtree_hits_cache 指令严格控制（以防缓存所有匹配“i am”的十六亿亿文档耗尽内存并立即导致服务器崩溃）。

[Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/rel 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/ext 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/ext 747541 (0,20)] [lj] the

[Sun Jul 12 15:18:17.062 2009] 0.059 sec [ext/0/rel 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.156 2009] 0.091 sec [ext/0/ext 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.250 2009] 0.092 sec [ext/0/ext 747541 (0,20)] [lj] the

注意多查询情况下每个查询的时间提升了 1.5 倍到 2.3 倍，具体取决于排序模式。

Manticore 支持通过 SQL 以以下格式进行 SELECT 子查询：

SELECT * FROM (SELECT ... ORDER BY cond1 LIMIT X) ORDER BY cond2 LIMIT Y

外层 select 只允许 ORDER BY 和 LIMIT 子句。子查询目前有两个使用场景：

1. 当你有一个包含两个排序 UDF 的查询，一个非常快，另一个很慢，并且执行全文搜索时匹配结果集很大。没有子查询，查询看起来像：

    SELECT id,slow_rank() as slow,fast_rank() as fast FROM index
        WHERE MATCH(‘some common query terms’) ORDER BY fast DESC, slow DESC LIMIT 20
        OPTION max_matches=1000;

   使用子查询，查询可以重写为：

    SELECT * FROM
        (SELECT id,slow_rank() as slow,fast_rank() as fast FROM index WHERE
            MATCH(‘some common query terms’)
            ORDER BY fast DESC LIMIT 100 OPTION max_matches=1000)
    ORDER BY slow DESC LIMIT 20;

   在初始查询中，slow_rank() UDF 会对整个匹配结果集进行计算。使用 SELECT 子查询时，只有 fast_rank() 会对整个匹配结果集计算，而 slow_rank() 只对有限的集合计算。

2. 第二种情况适用于来自分布式表的大型结果集。

   对于此查询：

    SELECT * FROM my_dist_index WHERE some_conditions LIMIT 50000;

   如果你有 20 个节点，每个节点最多可以向主节点发送 50K 条记录，结果是 20 x 50K = 1M 条记录。然而，由于主节点只返回 50K（从 1M 中），节点只发送前 10K 条记录可能就足够了。使用子查询，你可以将查询重写为：

    SELECT * FROM
         (SELECT * FROM my_dist_index WHERE some_conditions LIMIT 10000)
     ORDER by some_attr LIMIT 50000;

   在这种情况下，节点只接收内部查询并执行它。这意味着主节点只会收到 20x10K=200K 条记录。主节点将接收的所有记录重新排序（根据外层子句），并返回最好的 50K 条记录。子查询有助于减少主节点和节点之间的流量，同时减少主节点的计算时间（因为它只处理 200K 条记录，而不是 1M 条记录）。