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 之后才能设置。例如，您可能只想在主表中未找到结果时显示次级索引的结果，或者您可能需要根据第一个结果集中的匹配数量指定第二个结果集中的偏移量。在这种情况下，您将需要使用单独的查询（或单独的批处理）。

当使用连接器库时，例如 PHP 中的 mysqli，您可以添加多个查询，然后将它们作为一个批处理运行。这将作为一个单个多查询批处理工作。

注意：如果您使用控制台 MySQL 客户端，默认情况下它会将分号（;）解释为分隔符本身，并逐个将每个查询发送到服务器；这不是一个多查询批处理。要覆盖此行为，可以在客户端侧使用内部命令 delimiter 重新定义分隔符。在做出此更改后，客户端将发送整个包含分号的字符串，允许“多查询魔法”生效。

控制台客户端的这种行为有时会令人困惑，因为您可能会注意到相同的命令序列在 MySQL 客户端控制台中与 SQL-over-HTTP 等其他协议的行为有所不同。这是因为 MySQL 控制台客户端本身使用分号来划分查询，但其他协议可能会将整个序列作为一个批处理发送。

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

从控制台 MySQL/MariaDB 客户端：

DELIMITER _
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 指令严格控制（以确保缓存所有 160 亿个匹配“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 倍，具体取决于特定的排序模式。

多查询主要用于批处理查询并接收此类批处理的元数据。由于这一限制，批处理中只允许一小部分语句。在一个批处理中，您可以组合 SELECT、SHOW 和 SET 语句。

您可以像平常一样使用 SELECT；然而，请注意，所有查询将在一次通过中运行。如果查询之间没有关联，多查询就没有好处。守护进程会检测到这一点，并逐个运行查询。

你可以使用 SHOW 来处理 警告, 状态, 代理状态, 元数据, 配置文件 和 计划。所有其他在批次中的 SHOW 语句将被静默忽略，没有任何输出。例如，你不能执行 SHOW TABLES, SHOW THREADS, 或 SHOW VARIABLES，或任何其他未提及的语句进行批次处理。

你可以仅使用 SET 来设置 SET PROFILING。所有其他 SET ... 命令将被静默忽略。

执行的顺序也不同。守护进程在两轮中处理批次。

首先，它收集所有 SELECT 语句，并同时运行它看到的所有 SET PROFILING 语句。作为副作用，只有最后一个 SET PROFILING 语句有效。如果你执行一个类似的多查询语句，如 SET PROFILING=1; SELECT...; SHOW META; SHOW PROFILE; SET PROFILING=0，你将看不到任何配置文件，因为在第一轮中，守护进程执行了 SET PROFILING=1，然后立即执行了 SET PROFILING=0。

第二轮，守护进程尝试使用收集的所有 SELECT 语句执行单个批次查询。如果语句不相关，它将依次执行它们。

最后，它遍历初始批次序列，并返回结果集中的每个 SELECT 和 SHOW 的子结果数据和元数据。由于所有 SET PROFILING 语句在第一轮中已执行，因此在第二轮中将被跳过。 each SELECT and SHOW. Since all SET PROFILING statements were executed in the first pass, they are skipped on this second pass.

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 = 100万条记录。然而，由于主节点只返回 50K 条（从 100万条中），节点只发送前 10K 条记录可能就足够了。使用子查询，你可以将查询重写为：

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

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