在本文中，我们讨论了用于在 Manticore Search 中分析查询的工具。
SHOW META
默认情况下，SHOW META 命令提供有关匹配中使用的关键字的统计信息。对于每个关键字，我们获得找到该关键字的文档数量和总命中次数。高值 - 例如文档几乎与索引中的总文档数量相同 - 可能表明该关键字是停止词的候选者。
通过使用 –cpustats –iostats 启动 searchd 守护进程，可以丰富 SHOW META 的输出。这使得能够收集关于执行查询所需的输入输出和 CPU 资源的查询指标。
mysql> SELECT * FROM myindex WHERE MATCH('search engine*');SHOW META;
....
+-----------------------+---------+
| Variable_name | Value |
+-----------------------+---------+
| total | 1000 |
| total_found | 3994 |
| time | 0.090 |
| cpu_time | 42.950 |
| agents_cpu_time | 0.000 |
| io_read_time | 82.276 |
| io_read_ops | 1633 |
| io_read_kbytes | 1264.5 |
| io_write_time | 0.000 |
| io_write_ops | 0 |
| io_write_kbytes | 0.0 |
| agent_io_read_time | 0.000 |
| agent_io_read_ops | 0 |
| agent_io_read_kbytes | 0.0 |
| agent_io_write_time | 0.000 |
| agent_io_write_ops | 0 |
| agent_io_write_kbytes | 0.0 |
| keyword[0] | engine* |
| docs[0] | 55037 |
| hits[0] | 135095 |
| keyword[1] | search |
| docs[1] | 32768 |
| hits[1] | 53800 |
+-----------------------+---------+
23 rows in set (0.00 sec)
iostats 告诉我们从磁盘读取了多少数据，进行了多少 I/O 操作，以及花费了多长时间。大量的 I/O 数据读取意味着查询具有许多需要读取的命中，以便构建排名分数。如果数据量不大，但我们经历了高延迟，我们的存储可能很慢或过载。这可能是由于高流量造成的，但也可能表明存储存在需要调查的问题。
cpustats 提供了执行处理所使用的 CPU 时间。如果 I/O 统计数据较低而 CPU 占用较高，查询就会受到 CPU 限制。一般来说，可以通过将索引拆分为多个分片并使用 dist_threads > 0 执行本地集群搜索来解决 CPU 限制。长时间的 CPU 使用也可以表示服务器正在过载。高 CPU 使用时间可能有多种原因，常见的原因是由于通配符搜索（默认 dict=keywords）导致的扩展。
agent_ 指标在索引为分布式时具有值，并提供了主索引与其节点之间的读/写数据量。
SHOW PROFILE
可以通过
SET
PROFILING=1（或在 HTTP API 的情况下传递 profile:true）在每个会话中启用分析。
SHOW PROFILE
必须在查询后立即运行。它提供了查询执行不同阶段所花费的时间。switches 列提供了逻辑引擎状态切换的数量（不是操作系统级别的上下文切换）。阶段时间可以帮助理解查询为什么很慢。在下面的示例中，由于查询是在索引加载后立即执行的，因此在 read_* 阶段花费了很多时间，因为它必须从磁盘执行读取。对带有远程节点的分布式索引进行分析会添加连接代理和等待远程结果的阶段。
mysql> SHOW PROFILE;
+--------------+----------+----------+---------+
| Status | Duration | Switches | Percent |
+--------------+----------+----------+---------+
| unknown | 0.000827 | 4 | 0.91 |
| local_search | 0.000011 | 1 | 0.01 |
| sql_parse | 0.000019 | 1 | 0.02 |
| dict_setup | 0.000001 | 1 | 0.00 |
| parse | 0.000029 | 1 | 0.03 |
| transforms | 0.000104 | 1 | 0.11 |
| init | 0.000668 | 1169 | 0.73 |
| read_docs | 0.069948 | 1348 | 76.58 |
| read_hits | 0.012602 | 285 | 13.80 |
| get_docs | 0.004021 | 804 | 4.40 |
| get_hits | 0.002276 | 704 | 2.49 |
| filter | 0.000069 | 258 | 0.08 |
| rank | 0.000252 | 791 | 0.28 |
| sort | 0.000266 | 8 | 0.29 |
| finalize | 0.000234 | 1 | 0.26 |
| aggregate | 0.000014 | 2 | 0.02 |
| eval_post | 0.000000 | 1 | 0.00 |
| total | 0.091341 | 5380 | 0 |
+--------------+----------+----------+---------+
18 rows in set (0.00 sec)
SHOW PLAN
SHOW PLAN 显示评估的查询树的全文匹配。这对于理解输入搜索是如何转化和执行的非常有用。关键字以其在查询中的位置显示，并且如果它们是来自通配符项的扩展关键字。对于带有通配符的搜索，这个命令很有用，因为我们可以看到所有扩展的完整列表。
mysql> SHOW PLAN\G
*************************** 1. row ***************************
Variable: transformed_tree
Value: AND(
AND(KEYWORD(search, querypos=1)),
OR(
OR(
AND(KEYWORD(engineer, querypos=2, expanded)),
OR(
AND(KEYWORD(engineering, querypos=2, expanded)),
OR(
AND(KEYWORD(engineers, querypos=2, expanded)),
AND(KEYWORD(engines, querypos=2, expanded)))),
AND(KEYWORD(engineered, querypos=2, expanded))),
OR(
AND(KEYWORD(engine's, querypos=2, expanded)),
OR(
AND(KEYWORD(engine_power, querypos=2, expanded)),
AND(KEYWORD(engined, querypos=2, expanded)))),
AND(KEYWORD(engine, querypos=2, expanded)),
OR(KEYWORD(engine*, querypos=2, expanded))))
1 row in set (0.00 sec)
SHOW PLAN 还需要启用分析，并且必须在 SHOW META 之前运行。
最终，系统资源也需要被监控。如果您在 Manticore 之外运行其他活动服务（如数据库或应用程序代码），则需要监控这些服务的影响。虽然 Manticore 可以与其他服务共存，但由于它可能同时对 CPU 和 IO 密集，因此对于高流量的设置，最好让 Manticore 独立运行，以免受到（或影响）其他服务的影响。