当 Manticore 执行全表扫描查询时，它可以选择通过简单扫描检查每个文档是否符合过滤条件，或者使用额外的数据和算法来加速查询执行。Manticore 使用一种基于成本的优化器（CBO，也称为“查询优化器”）来决定采用哪种方法。
CBO 还可以提升全文查询的性能，详情如下。
如果 CBO 认为这样做能提升性能，它可能决定用以下实体之一替换一个或多个查询过滤器：
- docid 索引 使用存储在
.spt扩展名文件中的特殊 docid-only 次级索引。除了提升文档 ID 的过滤性能外，docid 索引还可用于加速文档 ID 到行 ID 的查找，并在守护程序启动时加速应用大型删除列表。 - 列式扫描 依赖于列式存储，只能用于列式属性。它会扫描每个值并根据过滤条件进行测试，但经过高度优化，通常比默认方法更快。
- 次级索引 默认情况下为所有属性（除 JSON 外）生成，使用 PGM 索引 和 Manticore 内置的倒排索引来检索与某个值或值范围相对应的行 ID 列表。次级索引存储在
.spidx和.spjidx扩展名的文件中。 关于如何为 JSON 属性生成次级索引，请参阅 json_secondary_indexes。
优化器使用多种属性统计信息来估算每条执行路径的成本，包括：
- 属性内数据分布的信息（直方图，存储在
.sphi文件中）。直方图在数据索引时自动生成，是 CBO 的主要信息来源。 - 来自 PGM（次级索引）的信息，有助于估计读取文档列表的数量。这有助于评估文档列表合并性能，并选择合适的合并算法（优先队列合并或位图合并）。
- 列式编码统计，用于估计列式数据解压性能。
- 列式最小最大树。CBO 使用直方图估算应用过滤器后剩余的文档数量，还需要确定过滤器处理了多少文档。对于列式属性，部分评估最小最大树用于此目的。
- 全文检索词典。CBO 利用术语统计数据估算评估全文检索树的成本。
优化器为查询中使用的每个过滤器计算执行成本。由于某些过滤器可以由多个不同的实体替换（例如，对于文档 ID，Manticore 可以使用简单扫描、docid 索引查找、列式扫描（如果文档 ID 是列式存储的）以及次级索引），优化器会评估所有可用的组合。然而，最大组合数量限制为1024个。
为了估算查询执行成本，优化器计算执行查询时最重要操作的估计成本。它使用预设的常数来表示每个操作的成本。
优化器比较每条执行路径的成本，并选择成本最低的路径来执行查询。
当处理带有属性过滤器的全文查询时，查询优化器在两种可能的执行路径之间做出决策。一种是执行全文查询，检索匹配结果并使用过滤器；另一种是用上述实体替换过滤器，获取行 ID 并将其注入到全文匹配树中。这样，全文检索结果将与全表扫描结果相交。查询优化器估算全文检索树的评估成本以及计算过滤器结果的最佳路径。根据这些信息，优化器选择执行路径。
另一个需要考虑的因素是多线程查询执行（当启用 pseudo_sharding 时）。CBO 知道某些查询可以在多个线程中执行，并将此考虑在内。CBO 优先考虑较短的查询执行时间（即延迟）而不是吞吐量。例如，如果使用列式扫描的查询可以在多个线程中执行（并占用多个CPU核心），且比使用单线程次级索引的查询更快，多线程执行将被优先选择。
使用次级索引和 docid 索引的查询总是在单线程中运行，因为基准测试表明将它们多线程化几乎没有任何好处。
目前，优化器只使用CPU成本，并不考虑内存或磁盘使用情况。