数据创建和修改 > 从外部存储添加数据

使用纯表格时，有一个挑战是需要确保表中的数据尽可能新鲜。

在这种情况下，一个或多个次要（也称为增量）表用于捕获主表创建时间和当前时间之间的修改数据。修改的数据可以包括新文档、更新文档或删除文档。搜索变成了在主表和增量表之间进行的搜索。当只是向增量表添加新文档时，这可以无缝工作，但当涉及到更新或删除文档时，仍然存在以下问题。

如果一个文档同时存在于主表和增量表中，在搜索时可能会出现问题，因为引擎会看到两个版本的文档，并不知道如何选择正确的版本。因此，增量表需要以某种方式通知搜索，主表中有应被忽略的已删除文档。这就是杀单列表发挥作用的地方。

一个表可以维护一个文档ID列表，用于抑制其他表中的记录。此功能适用于使用数据库源的纯表或使用XML源的纯表。对于数据库源，源需要提供一个额外的查询定义为sql_query_killlist。它将存储在表中的文档ID列表，服务器可以使用这些文档ID从其他纯表中移除文档。

该查询预期返回多行，每行包含一个仅有的文档ID。

在许多情况下，查询是一个检索更新文档列表和删除文档列表的联合查询，例如：

sql_query_killlist = \
    SELECT id FROM documents WHERE updated_ts>=@last_reindex UNION \
    SELECT id FROM documents_deleted WHERE deleted_ts>=@last_reindex

纯表可以包含一个名为killlist_target的指令，告诉服务器它可以提供一个文档ID列表，应该从某些现有表中移除。该表可以使用其文档ID作为此列表的来源，或者提供一个单独的列表。

设置将在其中应用杀单列表的表（可选，默认值为空）。

当你使用纯表时，你通常需要维护不止一个表，而是需要一组表以便更快地添加/更新/删除新文档（有关增量表更新的更多信息）。为了抑制在下一个（增量）表中更新或删除的新文档在上一个（主）表中的匹配项，你需要：

在增量表中创建一个杀单列表，使用sql_query_killlist
在增量表设置中指定主表作为killlist_target：

‹›

CONFIG

CONFIG

📋

table products {
  killlist_target = main:kl
  path = products
  source = src_base
}

当指定了killlist_target时，杀单列表会在searchd启动时应用于所有列出的表。如果killlist_target中的任何表被旋转，则重新应用这些表上的杀单列表。当杀单列表被应用时，受影响的表将这些更改保存到磁盘。

killlist_target有三种操作模式：

killlist_target = main:kl。增量表的杀单列表中的文档ID在主表中被抑制（参见sql_query_killlist）。
killlist_target = main:id。增量表中的所有文档ID在主表中被抑制。忽略杀单列表。
killlist_target = main。增量表及其杀单列表中的所有文档ID在主表中被抑制。

可以指定多个目标，用逗号分隔：

killlist_target = table_one:kl,table_two:kl

你可以通过使用ALTER而不重建表来更改表的killlist_target设置。

然而，由于“旧”的主表已经将更改写入磁盘，即使它不再在增量表的killlist_target中，之前在主表中删除的文档仍会保持删除状态。

‹›

SQL
HTTP

📋

ALTER TABLE delta KILLLIST_TARGET='new_main_table:kl'

将一个表附加到另一个表

Last modified: August 28, 2025

一个普通的表可以被转换为实时表或附加到现有的实时表。

第一种情况在需要完全重新生成实时表时有用，例如，如果需要更新分词设置。在这种情况下，准备一个普通的表并将其转换为实时表可能比创建批处理作业来插入所有数据到实时表更容易。

第二种情况是通常希望将大量新数据添加到实时表中，同样地，创建包含这些数据的普通表比填充现有实时表更容易。

你也可以将现有的实时表附加到另一个实时表。

ATTACH 语句允许将一个普通的表转换为附加到现有实时表的表。它还使一个实时表的内容能够附加到另一个实时表。

ATTACH TABLE plain_or_rt_table TO TABLE rt_table [WITH TRUNCATE]

成功执行 ATTACH 后，源普通表中原有的数据将成为目标RT表的一部分，并且源普通表变得不可用（直到下一次重建）。如果源表是一个RT表，则其内容将移动到目标RT表，源RT表保持为空。ATTACH 不会改变任何表的数据。本质上，它只是重命名文件（使源表成为目标RT表的新磁盘块）并更新元数据。因此，它通常是一个快速操作，可能会在不到一秒的时间内完成。

请注意，当一个表附加到一个空的RT表时，源表中的字段、属性和文本处理设置（分词器、词形变化等）会被复制并生效。配置文件中相应的RT表定义部分将被忽略。

当使用 TRUNCATE 选项时，在附加源普通表之前，RT表会被截断。这使得操作原子化或确保附加的源普通表将是目标RT表中的唯一数据。

ATTACH TABLE 具有一些限制。最值得注意的是，目标RT表当前必须为空或与源表具有相同的设置。如果源表被附加到一个非空的RT表，则迄今为止收集的RT表数据将作为常规磁盘块存储，而被附加的表将成为最新的磁盘块，具有相同ID的文档将被删除。完整的限制列表如下：

目标RT表需要为空或与源表具有相同的设置。
源表需要设置 phrase_boundary_step 为 0 和 stopword_step 为 1。

‹›

Example

Example

📋

在执行 ATTACH 之前，RT 表为空并且有 3 个字段：

mysql> DESC rt;
Empty set (0.00 sec)
mysql> SELECT * FROM rt;
+-----------+---------+
| Field     | Type    |
+-----------+---------+
| id        | integer |
| testfield | field   |
| testattr  | uint    |
+-----------+---------+
3 rows in set (0.00 sec)

普通的表不为空：

mysql> SELECT * FROM plain WHERE MATCH('test');
+------+--------+----------+------------+
| id   | weight | group_id | date_added |
+------+--------+----------+------------+
|    1 |   1304 |        1 | 1313643256 |
|    2 |   1304 |        1 | 1313643256 |
|    3 |   1304 |        1 | 1313643256 |
|    4 |   1304 |        1 | 1313643256 |
+------+--------+----------+------------+
4 rows in set (0.00 sec)

将普通的表附加到 RT 表：

mysql> ATTACH TABLE plain TO TABLE rt;
Query OK, 0 rows affected (0.00 sec)

现在，RT 表有 5 个字段：

mysql> DESC rt;
+------------+-----------+
| Field      | Type      |
+------------+-----------+
| id         | integer   |
| title      | field     |
| content    | field     |
| group_id   | uint      |
| date_added | timestamp |
+------------+-----------+
5 rows in set (0.00 sec)

并且它不为空：

mysql> SELECT * FROM rt WHERE MATCH('test');
+------+--------+----------+------------+
| id   | weight | group_id | date_added |
+------+--------+----------+------------+
|    1 |   1304 |        1 | 1313643256 |
|    2 |   1304 |        1 | 1313643256 |
|    3 |   1304 |        1 | 1313643256 |
|    4 |   1304 |        1 | 1313643256 |
+------+--------+----------+------------+
4 rows in set (0.00 sec)

在执行 ATTACH 之后，普通的表被移除并且不再可用于搜索：

mysql> SELECT * FROM plain WHERE MATCH('test');
ERROR 1064 (42000): no enabled local indexes to search

普通表中的 killlist 导入 RT 表

Last modified: August 28, 2025

如果您决定从 Plain 模式迁移到 RT 模式或在某些其他情况下，使用 Plain 模式构建的实时和 percolate 表可以通过 IMPORT TABLE 语句导入到运行 RT 模式的 Manticore。其通用语法如下：

IMPORT TABLE table_name FROM 'path'

其中 'path' 参数必须设置为：/your_backup_folder/your_backup_name/data/your_table_name/your_table_name

‹›

bash

bash

📋

mysql -P9306 -h0 -e 'create table t(f text)'
mysql -P9306 -h0 -e "backup table t to /tmp/"
mysql -P9306 -h0 -e "drop table t"
BACKUP_NAME=$(ls /tmp | grep 'backup-' | tail -n 1)
mysql -P9306 -h0 -e "import table t from '/tmp/$BACKUP_NAME/data/t/t'
mysql -P9306 -h0 -e "show tables"

执行此命令会将指定表的所有表文件复制到 data_dir。所有外部表文件，例如 wordforms、exceptions 和 stopwords 也会复制到相同的 data_dir。 IMPORT TABLE 有以下限制：

原配置文件中指定的外部文件路径必须为绝对路径
仅支持实时 (real-time) 和 percolate 表
普通 (plain) 表需要预先（在 plain 模式下）通过 ATTACH TABLE 转换为实时表

注意，IMPORT TABLE 命令不支持版本低于 5.0.0 创建的表。

如果上述将 plain 表迁移为 RT 表的方法不可行，您可以使用 indexer --print-rt 直接从 plain 表导出数据，无需将其转换为 RT 类型表，然后直接从命令行将导出内容导入到 RT 表中。

不过该方法有一些限制：

仅支持基于 SQL 的数据源
不支持 MVA

‹›

bash

bash

📋

/usr/bin/indexer --rotate --config /etc/manticoresearch/manticore.conf --print-rt my_rt_index my_plain_index > /tmp/dump_regular.sql
mysql -P $9306 -h0 -e "truncate table my_rt_index"
mysql -P 9306 -h0 < /tmp/dump_regular.sql
rm /tmp/dump_regular.sql

将一个表附加到另一个表旋转表

Last modified: August 28, 2025

表旋转是一种过程，其中 searchd 服务器查找配置中定义的表的新版本。旋转仅支持 Plain 模式的操作。

有两种情况：

对于已经加载的 Plain 表
在配置中添加但尚未加载的表

在第一种情况下，indexer 无法将表的新版本投入使用，因为运行中的副本已被 searchd 锁定和加载。此时需要以带有 --rotate 参数调用 indexer。如果使用 rotate，indexer 会创建名称中带有 .new. 的新表文件，并向 searchd 发送 HUP 信号，通知其有新版本。searchd 将执行查找操作，将新版本的表替换旧版本并丢弃旧版本。在某些情况下，可能希望先创建新版本表但不立即执行旋转。比如，可能先希望检查新表版本的健康状态。此时，indexer 可以接受 --nohup 参数，禁止向服务器发送 HUP 信号。

新表可以通过旋转加载；但是，常规处理 HUP 信号的方式是只有在服务器启动后配置发生更改时才检查新表。如果表已在配置中定义，应首先运行不带旋转的 indexer 创建表，然后执行 RELOAD TABLES 语句。

还有两个专用语句可以用于对表执行旋转：

RELOAD TABLE tbl [ FROM '/path/to/table_files' [ OPTION switchover=1 ] ];

RELOAD TABLE 命令通过 SQL 实现表旋转。

此命令有三种模式。第一种模式是不指定路径，Manticore 服务器会检查由 path 指定的目录中新表文件。新表文件必须命名为 tbl.new.sp?。

如果指定路径，服务器会在该目录搜索表文件，将它们移动到表的 path，将文件名从 tbl.sp? 重命名为 tbl.new.sp?，并旋转它们。

第三种模式由 OPTION switchover=1 激活，将索引切换到新的路径。此时，守护进程尝试直接从新路径加载表而不移动文件。如果加载成功，这个新索引将取代旧索引。

此外，守护进程会在由 path 指定的目录中写入唯一链接文件（tbl.link），保持持久重定向。

如果将已重定向的索引恢复到配置中指定的路径，守护进程会检测到这一点并删除链接文件。

一旦重定向，守护进程从新的链接路径获取表。旋转时，它会在新的重定向路径查找新表版本。需要注意的是，守护进程会检查配置中的常见错误，比如不同表的路径重复，但不会识别多个表通过重定向指向同一路径的情况。正常操作下，表通过 .spl 文件锁定，但禁用锁定可能会导致问题。如果出现错误（例如路径因某种原因无法访问），需要手动修正（或简单删除）链接文件。

indextool 会跟随链接文件，但其他工具（indexer、index_converter 等）不识别链接文件，始终使用配置文件中定义的路径，忽略任何重定向。因此，可以用 indextool 检查索引，它会从新位置读取；但更复杂的操作如合并将不识别任何链接文件。

mysql> RELOAD TABLE plain_table;
mysql> RELOAD TABLE plain_table FROM '/home/mighty/new_table_files';
mysql> RELOAD TABLE plain_table FROM '/home/mighty/new/place/for/table/table_files' OPTION switchover=1;

RELOAD TABLES;

此命令的功能类似于 HUP 系统信号，触发表的旋转。但它并不完全等同于典型的 HUP 信号（例如通过 kill -HUP 命令或 indexer --rotate 触发）。该命令会主动查找需要旋转的表，并能重新读取配置。比如，若以配置文件启动的 Manticore 处于 Plain 模式，但配置指向一个不存在的 Plain 表，之后执行 indexer --rotate 不会让服务器识别新表，需执行 RELOAD TABLES 或重启服务器。

根据 seamless_rotate 设置的值，新查询可能会被短暂挂起，客户端会收到临时错误。

mysql> RELOAD TABLES;
Query OK, 0 rows affected (0.01 sec)

旋转假设旧表版本被丢弃，新表版本被加载并替换现有表。在交换期间，服务器还需处理对即将更新表的入站查询。为了避免查询阻塞，服务器默认实现了表的无缝旋转，如下所述。

表可能包含需要预缓存到内存的数据。目前，.spa、.spb、.spi 和 .spm 文件是完全预缓存的（它们分别包含属性数据、二进制大对象属性数据、关键词表和已删除行映射）。如果不使用无缝旋转，旋转表尽可能少占用内存，工作流程如下：

临时拒绝新查询（返回“重试”错误码）。
searchd 等待所有正在运行的查询完成。
释放旧表并重命名其文件。
重命名新表文件并分配所需内存。
将新表属性和字典数据预加载到内存。
searchd 继续从新表处理查询。

不过，如果属性或字典数据量较大，则预加载步骤可能需要明显时间——在预加载 1-5+ GB 文件时可能达数分钟。

开启无缝旋转后，旋转过程如下：

分配新的表的RAM存储。
异步预加载新表的属性和字典数据到RAM。
成功后，释放旧表并重命名两个表的文件。
失败时，释放新表。
在任何时刻，查询要么由旧表副本提供，要么由新表副本提供。

无缝旋转的代价是在旋转期间内存使用的峰值更高（因为预加载新副本时，旧副本和新副本的.spa/.spb/.spi/.spm数据都需要在RAM中）。不过平均使用量保持不变。

示例：

seamless_rotate = 1

导入 RT 表更新文档

Last modified: August 28, 2025

在纯表格中的杀单列表

表杀单列表

纯表中移除文档

killlist_target

将一个表附加到另一个表

附加表 - 通用语法

导入表

indexer --print-rt

旋转表

RELOAD TABLE

RELOAD TABLES

无缝旋转