随着时间的推移，RT 表可能会碎片化为多个磁盘块和/或被删除但未清除的数据污染，从而影响搜索性能。在这些情况下，需要进行优化。本质上，优化过程会合并磁盘块（N 路合并），并移除之前使用 DELETE 语句删除的文档。

从 Manticore 4 开始，此过程默认自动执行。但是，您也可以使用以下命令手动启动表压缩。

OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]]

OPTIMIZE TABLE rt;

POST /sql?mode=raw -d "OPTIMIZE TABLE rt"

OPTIMIZE TABLE rt OPTION cutoff=4;

POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION cutoff=4"

OPTIMIZE TABLE rt OPTION sync=1;

POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION sync=1"

优化可能是一个漫长且 I/O 强度高的过程。OPTIMIZE 语句会将任务添加到后台工作池中。您可以使用 parallel_chunk_merges 控制并行运行的任务数量，使用 merge_chunks_per_job 控制每个任务合并的块数。优化工作线程可以被 I/O 限流，您可以使用 rt_merge_iops 和 rt_merge_maxiosize 指令分别控制每秒最大 I/O 数和最大 I/O 大小。

在优化期间，正在优化的 RT 表几乎始终在线，并且可用于搜索和更新。当一对磁盘块成功合并时，表会被短暂锁定，以允许重命名旧文件和新文件并更新表头。

只要 auto_optimize 未被禁用，表就会自动优化。

如果您遇到意外的 SST 或希望集群中所有节点的表二进制相同，您需要：

1. 禁用 auto_optimize。
2. 手动优化表：

ALTER CLUSTER mycluster DROP myindex;

POST /sql?mode=raw -d "ALTER CLUSTER mycluster DROP myindex"

OPTIMIZE TABLE myindex;

POST /sql?mode=raw -d "OPTIMIZE TABLE myindex"

ALTER CLUSTER mycluster ADD myindex;

POST /sql?mode=raw -d "ALTER CLUSTER mycluster ADD myindex"

当表重新添加到集群中时，优化过程创建的新文件将被复制到集群中的其他节点。 其他节点上对表的任何本地更改都将丢失。

表数据修改（插入、替换、删除、更新）应：

1. 延迟，或
2. 指向正在运行优化过程的节点。

请注意，当表不在集群中时，插入/替换/删除/更新命令应不带集群名称前缀引用它（对于 SQL 语句或 HTTP JSON 请求中的集群属性），否则它们将失败。 一旦表重新添加到集群中，您必须恢复对表的写入操作并再次包含集群名称前缀，否则它们将失败。

在过程中，搜索操作在任何节点上都可以正常使用。

Manticore 在实时表的刷新和合并过程中提供隔离，防止任何更改影响正在运行的查询。

例如，在表压缩期间，一对磁盘块会被合并并产生一个新的块。在某个时刻，会创建表的新版本，新块替换了原始的这一对块。这一过程是无缝进行的，因此使用原始块的长时间运行的查询将继续看到旧版本的表，而新的查询将看到包含合并后块的新版本。

同样适用于刷新 RAM 块的情况，此时合适的 RAM 段会被合并成新的磁盘块，而参与的 RAM 块段则被放弃。在此操作期间，Manticore 对操作开始前启动的查询提供隔离。

此外，这些操作对替换和更新是透明的。如果您更新属于正在与另一个块合并的磁盘块中的文档的属性，更新将应用于该块和合并后生成的新块。如果在合并期间删除文档，该文档将同时在原始块和合并后生成的新块中被删除，新块要么将该文档标记为已删除，要么如果删除发生在合并过程的早期，则根本不会包含该文档。

“冻结”表在你想制作物理副本或备份时很有用。它会将表文件标记为已冻结，并显示这些文件的存放位置。冻结后，你可以安全地将这些文件复制到其他地方。被冻结的表仍然可以继续添加新文档，直到达到 rt_mem_limit，但这些新数据只会留在内存中，在表解冻之前不会写入磁盘。如果表超过了 rt_mem_limit，所有更改都会暂停，直到表被解冻。如果守护进程意外停止，任何未保存的数据都会从 binlog 中恢复。

“锁定”表适用于逻辑备份。它不会停止内部维护任务，例如磁盘块合并操作或将 RAM 块写入磁盘。它只会阻止写入操作。这意味着你不能向已锁定的表中插入、替换或更新数据。这对 mysqldump 之类的工具很有帮助，因为锁定可以确保数据在逻辑上保持一致。比如说，如果在转储期间替换了一条文档记录，在没有锁的情况下，旧版本可能已经出现在转储里，而新版本也可能随后出现，而且两者的文档 ID 相同。锁定表可以避免这种情况。

FREEZE tbl1[, tbl2, ...]

FREEZE t;

+-------------------+---------------------------------+
| file              | normalized                      |
+-------------------+---------------------------------+
| data/t/t.0.spa    | /work/anytest/data/t/t.0.spa    |
| data/t/t.0.spd    | /work/anytest/data/t/t.0.spd    |
| data/t/t.0.spds   | /work/anytest/data/t/t.0.spds   |
| data/t/t.0.spe    | /work/anytest/data/t/t.0.spe    |
| data/t/t.0.sph    | /work/anytest/data/t/t.0.sph    |
| data/t/t.0.sphi   | /work/anytest/data/t/t.0.sphi   |
| data/t/t.0.spi    | /work/anytest/data/t/t.0.spi    |
| data/t/t.0.spm    | /work/anytest/data/t/t.0.spm    |
| data/t/t.0.spp    | /work/anytest/data/t/t.0.spp    |
| data/t/t.0.spt    | /work/anytest/data/t/t.0.spt    |
| data/t/t.meta     | /work/anytest/data/t/t.meta     |
| data/t/t.ram      | /work/anytest/data/t/t.ram      |
| data/t/t.settings | /work/anytest/data/t/t.settings |
+-------------------+---------------------------------+
13 rows in set (0.01 sec)

file 列表示运行中的实例在 data_dir 内对应的表文件路径。normalized 列显示这些文件的绝对路径。要备份表，只需直接复制提供的文件，无需额外准备。

当表被冻结时，你不能执行 UPDATE 查询；它们会一直等待到表解冻为止。

另外，在表被冻结期间，DELETE 和 REPLACE 查询也有一些限制：

• 如果 DELETE 作用于当前 RAM 块中的文档，则允许执行。
• 如果 DELETE 影响的是磁盘块中的文档，但该文档之前已经被删除，则允许执行。
• 如果 DELETE 会修改实际的磁盘块，则会等待直到表被解冻。

手动对冻结表的 RAM 块执行 FLUSH 会返回“success”，但实际上不会发生真正的保存。

冻结表上的 DROP/TRUNCATE 是允许的，因为这些操作不是隐式的。我们假设如果你要截断或删除一张表，就不需要为它做备份；因此，它本来就不应该被冻结。

向冻结表执行 INSERT 是支持的，但有上限：新数据会像平常一样先存入 RAM，直到达到 rt_mem_limit；之后新的插入会等待，直到表解冻。

如果你在有冻结表的情况下关闭守护进程，它的行为会像经历了一次非正常关机（例如 kill -9）：新插入的数据不会被保存到磁盘上的 RAM 块中，重启后会从二进制日志中恢复（如果有的话），否则就会丢失（如果禁用了二进制日志）。

UNFREEZE tbl1[, tbl2, ...]

UNFREEZE tbl;

SHOW TABLE `foo` STATUS LIKE 'locked';

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| locked        | 2     |
+---------------+-------+
1 row in set (0,00 sec)

lock tables tbl1 read[, tbl2 read, ...]

--------------
LOCK TABLES tbl READ
--------------
Query OK, 0 rows affected (0.000 sec)
--------------
LOCK TABLES tbl READ, tbl2 WRITE
--------------
Query OK, 0 rows affected, 1 warning (0.000 sec)
--------------
SHOW WARNINGS
--------------
+---------+------+--------------------------------+
| Level   | Code | Message                        |
+---------+------+--------------------------------+
| warning | 1000 | Write lock is not implemented. |
+---------+------+--------------------------------+
1 row in set (0.000 sec)

UNLOCK TABLES;

SHOW LOCKS;

+-----------+------+-----------+-----------------+
| Type      | Name | Lock Type | Additional Info |
+-----------+------+-----------+-----------------+
| rt        | a    | read      | Count: 1        |
| percolate | bar  | freeze    | Count: 3        |
| rt        | foo  | freeze    | Count: 2        |
+-----------+------+-----------+-----------------+
3 rows in set (0,01 sec)