SYSTEM RELOAD EMBEDDED DICTIONARIES
重新加载所有内部字典。 默认情况下，内部字典处于禁用状态。 无论内部字典的更新结果如何，始终返回Ok.。
SYSTEM RELOAD DICTIONARIES
SYSTEM RELOAD DICTIONARIES 查询会重新加载状态为 LOADED 的字典 (参见 system.dictionaries 的 status 列) ，即此前已成功加载的字典。
默认情况下，字典采用延迟加载 (参见 dictionaries_lazy_load) ，因此不会在启动时自动加载，而是在首次访问时通过调用 dictGet 函数，或对 ENGINE = Dictionary 的表执行 SELECT 时初始化。
语法
SYSTEM RELOAD 字典
彻底重新加载字典dictionary_name，无论该字典当前处于何种状态 (LOADED / NOT_LOADED / FAILED) 。
无论字典更新结果如何，始终返回 Ok.。
system.dictionaries 表来查看字典的状态。
SYSTEM UNLOAD 字典
如果字典状态为LOADED，则卸载字典 dictionary_name 以释放其占用的内存。
该字典会在后续再次需要时按需重新加载。
system.dictionaries 表来查看字典状态。
SYSTEM UNLOAD DICTIONARIES
SYSTEM UNLOAD DICTIONARIES 查询会卸载所有状态为 LOADED 的字典 (参见 system.dictionaries 的 status 列) ，即所有此前已成功加载的字典。
SYSTEM RELOAD FUNCTIONS
从配置文件中重新加载所有已注册的可执行用户自定义函数，或重新加载其中一个。 语法SYSTEM RELOAD ASYNCHRONOUS METRICS
重新计算所有异步指标。由于异步指标会根据设置 asynchronous_metrics_update_period_s 定期更新，因此通常无需使用此语句手动更新。SYSTEM CLEAR|DROP DNS CACHE
清除 ClickHouse 的内部 DNS 缓存。有时 (对于较旧版本的 ClickHouse) ，在基础设施发生变更时 (例如更改另一台 ClickHouse server 或字典所使用 server 的 IP 地址) ，需要使用此命令。 如需更方便地 (自动) 管理缓存，请参见disable_internal_dns_cache、dns_cache_max_entries、dns_cache_update_period 参数。
SYSTEM CLEAR|DROP 标记缓存
清空标记缓存。SYSTEM CLEAR|DROP PRIMARY INDEX CACHE
清除主索引缓存。该缓存会在内存中保存MergeTree 表的主键。
其大小由服务器级设置 primary_index_cache_size 控制。
SYSTEM CLEAR|DROP ICEBERG METADATA CACHE
清空 Iceberg 元数据缓存。SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
清除AvroConfluent 格式使用的、按 URL 区分的 Confluent Schema Registry 缓存。这会同时删除 schema 拉取缓存 (id → schema) 和 schema 注册缓存 (subject + schema → id) ，因此后续的读写都会回退到 registry 服务器。当 registry 端的 schema 被删除或改写时，此功能非常有用；也可用于在测试中验证 registry 的幂等性。
SYSTEM DROP PARQUET METADATA CACHE
清空 Parquet 元数据缓存。SYSTEM CLEAR|DROP PAIMON METADATA CACHE
清除已解析的 Paimon 元数据文件 (manifest 列表和 manifests) 的内存缓存。SYSTEM CLEAR|DROP POINT IN POLYGON CACHE
清除函数pointInPolygon 使用的预处理常量多边形缓存。已配置的大小限制 (服务器设置 point_in_polygon_cache_size) 保持不变，因此之后缓存仍会继续接受新条目。若要禁用该缓存，请将 point_in_polygon_cache_size 设为 0。
SYSTEM CLEAR|DROP TEXT INDEX CACHES
清除文本索引的标记、头部和倒排列表缓存。 如果要单独清除其中某一个缓存，可以运行SYSTEM CLEAR TEXT INDEX TOKENS CACHE,SYSTEM CLEAR TEXT INDEX HEADER CACHE，或SYSTEM CLEAR TEXT INDEX POSTINGS CACHE
SYSTEM CLEAR|DROP INDEX MARK CACHE
清除次级 (数据跳过) 索引的标记缓存。SYSTEM CLEAR|DROP INDEX UNCOMPRESSED CACHE
清除次级 (数据跳过) 索引的未压缩块缓存。SYSTEM CLEAR|DROP MMAP CACHE
清除内存映射文件缓存。SYSTEM CLEAR|DROP PAGE CACHE
清除用户态页缓存，即 ClickHouse 自有的内存缓存，用于缓存从底层存储读取的数据。SYSTEM CLEAR|DROP VECTOR SIMILARITY INDEX CACHE
清空向量相似度索引缓存。SYSTEM CLEAR|DROP CONNECTIONS CACHE
清除用于对外连接的 HTTP 连接池缓存。SYSTEM CLEAR|DROP S3 CLIENT CACHE
清除 S3 客户端的缓存。SYSTEM PREWARM MARK CACHE
将表的标记预加载到标记缓存中。次级索引的标记也会预加载到索引标记缓存中。SYSTEM PREWARM PRIMARY INDEX CACHE
将MergeTree 表的主索引加载至主索引缓存中。
SYSTEM CLEAR|DROP DISK METADATA CACHE
清除指定磁盘上的元数据缓存。SYSTEM SYNC FILESYSTEM CACHE
将 ClickHouse 文件系统缓存的内存状态与磁盘上实际存在的缓存文件进行同步，并返回每个已缓存 File 段的cache_name、path 和已下载的 size。可选的缓存名称可将该操作限制为仅针对单个缓存。
SYSTEM CLEAR|DROP DISTRIBUTED CACHE
SYSTEM CLEAR|DROP DISTRIBUTED CACHE 仅在 ClickHouse Cloud 中可用。CONNECTIONS 可仅删除与分布式缓存服务器之间的缓存连接，或者传入服务器标识符以仅针对某一台服务器。
SYSTEM DROP REPLICA
可以使用以下语法删除ReplicatedMergeTree 表的失效副本：
ReplicatedMergeTree 的副本路径。当某个副本已失效，且由于对应的表已不存在，无法通过 DROP TABLE 从 ZooKeeper 中删除其元数据时，这一操作就很有用。它只会删除非活动/过期副本，不能删除本地副本；这种情况请使用 DROP TABLE。DROP REPLICA 不会删除任何表，也不会从磁盘中移除任何数据或元数据。
第一种会删除 database.table 表中 'replica_name' 副本的元数据。
第二种会对该数据库中的所有复制表执行相同操作。
第三种会对本地服务器上的所有复制表执行相同操作。
第四种在某个表的所有其他副本都已被删除时，可用于删除失效副本的元数据。它要求显式指定表路径。该路径必须与创建表时传给 ReplicatedMergeTree 引擎第一个参数的路径相同。
SYSTEM DROP DATABASE REPLICA
可使用以下语法删除Replicated 数据库的失效副本：
SYSTEM DROP REPLICA 类似，但当没有可执行 DROP DATABASE 的数据库时，它会从 ZooKeeper 中移除 Replicated 数据库的副本路径。请注意，它不会移除 ReplicatedMergeTree 的副本 (因此你可能还需要使用 SYSTEM DROP REPLICA) 。分片名和副本名是在创建数据库时于 Replicated 引擎参数中指定的名称。此外，这些名称也可以从 system.clusters 的 database_shard_name 和 database_replica_name 列中获取。如果缺少 FROM SHARD 子句，那么 replica_name 必须是完整的副本名称，格式为 shard_name|replica_name。
SYSTEM CLEAR|DROP UNCOMPRESSED CACHE
清除未压缩数据缓存。 可通过查询/用户/profile 级设置use_uncompressed_cache 启用或禁用未压缩数据缓存。
其大小可通过服务器级设置 uncompressed_cache_size 配置。
SYSTEM CLEAR|DROP 编译 expression 缓存
清除已编译表达式缓存。 可通过查询/用户/profile 级设置compile_expressions 启用或禁用已编译表达式缓存。
SYSTEM CLEAR|DROP QUERY CONDITION CACHE
清除查询条件缓存。SYSTEM CLEAR|DROP ENCRYPTION HEADERS CACHE
清除加密头缓存。该缓存保存从加密文件开头读取的加密头，供 Experimentaluse_reader_executor 读取路径使用，以避免重复读取；其大小由服务器级设置 encryption_header_cache_size 配置。
SYSTEM CLEAR|DROP 查询缓存
SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE
清除从format_schema_path 加载的 schema 缓存。
支持的目标：
- Protobuf：从内存中移除已导入的 Protobuf 消息定义。
- Files：删除本地
format_schema_path中缓存的 schema 文件，这些文件会在format_schema_source设置为query时生成。 注意：如果未指定目标，则会同时清除这两类缓存。
SYSTEM FLUSH LOGS
将缓冲的日志消息刷写到系统表中，例如 system.query_log。该操作主要用于调试，因为大多数系统表默认的刷写时间间隔为 7.5 秒。 即使消息队列为空，也会创建系统表。SYSTEM RELOAD CONFIG
重新加载 ClickHouse 配置。用于配置存储在 ZooKeeper 中时的场景。请注意，SYSTEM RELOAD CONFIG 不会重新加载存储在 ZooKeeper 中的 USER 配置；它只会重新加载存储在 users.xml 中的 USER 配置。要重新加载所有 USER 配置，请使用 SYSTEM RELOAD USERS
SYSTEM RELOAD USERS
重新加载所有访问存储，包括：users.xml、本地磁盘访问存储、位于 ZooKeeper 中的复制访问存储。SYSTEM SHUTDOWN
通常用于关闭 ClickHouse (类似于service clickhouse-server stop / kill {$pid_clickhouse-server})
SYSTEM KILL
终止 ClickHouse 进程 (如kill -9 {$ pid_clickhouse-server})
SYSTEM INSTRUMENT
使用 LLVM 的 XRay 功能管理插桩点；该功能仅在以ENABLE_XRAY=1 构建 ClickHouse 时可用。
这使得无需修改源代码，也能以极低开销在生产环境中进行调试和性能分析。
在未添加任何插桩点时，性能损耗几乎可以忽略不计，因为它只会在长度超过 200 条指令的函数序言和结语处，
额外增加一次跳转到附近地址的操作。
SYSTEM INSTRUMENT ADD
添加一个新的插桩点。已插桩的函数可在system.instrumentation 系统表中查看。可以为同一函数添加多个 handler，它们会按插桩添加的顺序依次执行。
要进行插桩的函数可从 system.symbols 系统表中获取。
可向函数添加三种不同类型的 handler：
语法
FUNCTION 可以是任意函数，或函数名的一部分 (子串) ，例如 QueryMetricLog::startQuery；而 handler 则为以下之一
LOG
在函数的ENTRY 或 EXIT 时，打印作为参数传入的文本以及堆栈跟踪。
SLEEP
在ENTRY 或 EXIT 时休眠固定秒数：
PROFILE
用于衡量函数从ENTRY 到 EXIT 之间所花费的时间。
性能分析结果存储在 system.trace_log 中，并可转换为
Chrome Event Trace Format。
SYSTEM INSTRUMENT REMOVE
可使用以下方式移除单个插桩点：ALL 关键字对它们全部进行操作：
system.instrumentation 系统表中获取插桩点信息。
管理分布式表
ClickHouse 可以管理Distributed表。当用户向这些表插入数据时，ClickHouse 会先为需要发送到集群节点的数据创建一个队列，然后再异步发送。你可以使用STOP DISTRIBUTED SENDS、FLUSH DISTRIBUTED 和 START DISTRIBUTED SENDS 查询来控制队列处理。你也可以通过 distributed_foreground_insert 设置，以同步方式向分布式表插入数据。
SYSTEM STOP DISTRIBUTED SENDS
禁用向分布式表插入数据时的后台数据分发。如果启用了
prefer_localhost_replica (默认启用) ，数据仍会照常插入本地分片。SYSTEM FLUSH DISTRIBUTED
强制 ClickHouse 以同步方式将数据发送到集群节点。如果有任何节点不可用，ClickHouse 会抛出异常并停止执行查询。你可以重试该查询，直到成功；当所有节点恢复在线后，查询就会成功。 你也可以通过SETTINGS 子句覆盖某些设置，这有助于规避一些临时限制，例如 max_concurrent_queries_for_all_users 或 max_memory_usage。
每个待处理的块都会按照初始 INSERT 查询中的设置存储到磁盘上，因此有时你可能需要覆盖这些设置。
SYSTEM START DISTRIBUTED SENDS
启用向分布式表插入数据时的后台数据分发。SYSTEM STOP LISTEN
关闭套接字，并在指定端口上以指定协议优雅地终止与服务器的现有连接。 但如果未在 clickhouse-server 配置中指定相应的协议设置，此命令将不会生效。- 如果指定了
CUSTOM 'protocol'修饰符，则会停止在服务器配置的 protocols 部分中定义的、名称为指定值的自定义协议。 - 如果指定了
QUERIES ALL [EXCEPT .. [,..]]修饰符，则会停止所有协议，除非在EXCEPT子句中指定了排除项。 - 如果指定了
QUERIES DEFAULT [EXCEPT .. [,..]]修饰符，则会停止所有默认协议，除非在EXCEPT子句中指定了排除项。 - 如果指定了
QUERIES CUSTOM [EXCEPT .. [,..]]修饰符，则会停止所有自定义协议，除非在EXCEPT子句中指定了排除项。
SYSTEM START LISTEN
允许在指定协议上建立新的连接。 但是，如果指定端口和协议上的 server 不是通过 SYSTEM STOP LISTEN 命令停止监听的，则此命令不会生效。管理 MergeTree 表
ClickHouse 支持管理 MergeTree 表中的后台进程。SYSTEM STOP MERGES
可停止 MergeTree 家族中的表的后台合并：对表执行
DETACH / ATTACH 后，即使此前已对所有 MergeTree 表停止合并，也会重新为该表启动后台合并。SYSTEM START MERGES
可用于启动 MergeTree 家族中的表的后台合并：SYSTEM STOP TTL MERGES
可停止 MergeTree 家族中的表根据 TTL expression 在后台删除旧数据： 即使表不存在或表未使用 MergeTree 引擎，也会返回Ok.。当数据库不存在时，会返回错误：
SYSTEM START TTL MERGES
可为 MergeTree 家族中的表按 TTL expression 启动后台旧数据删除： 即使表不存在，也会返回Ok.。如果数据库不存在，则返回错误：
SYSTEM STOP MOVES
用于停止对 MergeTree 家族中的表按照带有 TO VOLUME 或 TO DISK 子句的表 TTL 表达式执行的后台数据移动： 即使表不存在，也会返回Ok.。如果数据库不存在，则会返回错误：
SYSTEM START MOVES
可为 MergeTree 家族中的表启动后台数据移动，这些移动依据带有 TO VOLUME 和 TO DISK 子句的表 TTL 表达式执行： 即使表不存在，也会返回Ok.。当数据库不存在时，则返回错误：
SYSTEM UNFREEZE
从所有磁盘中清除具有指定名称的冻结备份。有关解冻单个 parts 的更多信息，请参见 ALTER TABLE table_name UNFREEZE WITH NAMESYSTEM WAIT LOADING PARTS
等待，直到表中所有异步加载的数据分区片段 (过期数据分区片段) 均已完成加载。管理 ReplicatedMergeTree 表
ClickHouse 可以管理 ReplicatedMergeTree 表中与后台复制相关的进程。SYSTEM STOP FETCHES
可停止ReplicatedMergeTree 家族表中已插入 parts 的后台拉取操作：
无论表引擎为何，甚至表或数据库不存在，始终返回 Ok.
SYSTEM START FETCHES
可为ReplicatedMergeTree 家族中的表启动针对已插入 parts 的后台拉取：
无论表引擎是什么，甚至表或数据库不存在，也始终返回 Ok.。
SYSTEM STOP REPLICATED SENDS
可停止ReplicatedMergeTree 家族表中新插入的 parts 向集群中其他副本的后台发送：
SYSTEM START REPLICATED SENDS
可为ReplicatedMergeTree 家族中的表启动后台发送，将新插入的 parts 发送到集群中的其他副本：
SYSTEM STOP REPLICATION QUEUES
可停止存储在 Zookeeper 中、供ReplicatedMergeTree 家族表使用的复制队列里的后台拉取任务。可能的后台任务类型包括：合并、拉取、变更，以及带有 ON CLUSTER 子句的 DDL 语句：
SYSTEM START REPLICATION QUEUES
可为ReplicatedMergeTree 家族中的表启动存储在 ZooKeeper 中的复制队列里的后台任务。可能的后台任务类型包括：合并、拉取、变更，以及带有 ON CLUSTER 子句的 DDL 语句：
SYSTEM STOP PULLING REPLICATION LOG
停止将新条目从复制日志加载到ReplicatedMergeTree 表的复制队列中。
SYSTEM START PULLING REPLICATION LOG
撤销SYSTEM STOP PULLING REPLICATION LOG 的效果。
SYSTEM SYNC REPLICA
等待ReplicatedMergeTree 表与集群中的其他副本完成同步，但等待时间不超过 receive_timeout 秒。
[db.]replicated_merge_tree_family_table_name 会将公共复制日志中的命令拉取到自己的复制队列中，然后该查询会一直等待，直到副本处理完所有已拉取的命令。支持以下修饰符：
- 使用
IF EXISTS(自 25.6 起可用) 时，如果表不存在，查询不会抛出错误。这在向集群中添加新副本时很有用：此时它可能已经属于集群配置的一部分，但表仍在创建和同步过程中。 - 如果指定了
STRICT修饰符，则查询会等待复制队列清空。如果复制队列中持续出现新的条目，则STRICT版本可能永远不会成功。 - 如果指定了
LIGHTWEIGHT修饰符，则查询仅等待GET_PART、ATTACH_PART、DROP_RANGE、REPLACE_RANGE和DROP_PART条目处理完成。 此外，LIGHTWEIGHT修饰符还支持可选的FROM 'srcReplicas'子句，其中'srcReplicas'是以逗号分隔的源副本名称列表。此扩展可实现更有针对性的同步，只关注源自指定源副本的复制任务。 - 如果指定了
PULL修饰符，则查询会从 ZooKeeper 拉取新的复制队列条目，但不会等待任何内容被处理。
SYNC DATABASE REPLICA
等待指定的Replicated 数据库应用该数据库 DDL 队列中的所有 schema 变更。 语法SYSTEM RESTART REPLICA
可重新初始化ReplicatedMergeTree 表的 Zookeeper 会话状态；系统会将当前状态与作为事实来源的 Zookeeper 进行比较，并在需要时向 Zookeeper 队列添加任务。
基于 ZooKeeper 数据初始化复制队列的方式与 ATTACH TABLE 语句相同。在短时间内，该表将暂时无法执行任何操作。
SYSTEM RESTORE REPLICA
如果数据[可能]仍然存在，但 ZooKeeper 元数据已丢失，则可恢复副本。 仅适用于只读的ReplicatedMergeTree 表。
可在以下情况发生后执行该查询：
- ZooKeeper 根路径
/丢失。 - 副本路径
/replicas丢失。 - 单个副本路径
/replicas/replica_name/丢失。
所有状态的 parts 都会被移到
detached/ 文件夹中。数据丢失前处于活动状态 (committed) 的 parts 会被附加。SYSTEM RESTORE DATABASE REPLICA
在[可能]存在数据但 Zookeeper 元数据已丢失时，恢复副本。 语法SYSTEM RESTART REPLICAS
可为所有ReplicatedMergeTree 表重新初始化 Zookeeper 会话状态；它会将当前状态与 Zookeeper 中的状态进行比较，并以 Zookeeper 中的状态为准，必要时向 Zookeeper 队列添加任务
SYSTEM CLEAR|DROP FILESYSTEM CACHE
用于清空文件系统缓存。SYSTEM SYNC FILE CACHE
此操作开销过大，且存在被滥用的风险。
SYSTEM LOAD PRIMARY KEY
加载指定表或所有表的主键。SYSTEM UNLOAD PRIMARY KEY
卸载指定表或所有表的主键。管理可刷新的 materialized view
用于控制可刷新的 materialized view执行的后台任务的命令 在使用这类视图时，请留意system.view_refreshes。
SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS
禁用指定视图或所有可刷新的视图的周期性刷新。如果当前有刷新正在进行，也会一并取消。 如果视图位于 Replicated 或 Shared 数据库 中，STOP VIEW 仅影响当前副本，而 STOP REPLICATED VIEW 会影响所有副本。
停止后的状态不会在 server 重启后保留。重启后，视图将恢复按其已配置的刷新计划执行。
在 Replicated 或 Shared 数据库 中，
SYSTEM STOP VIEW 仅影响当前副本。使用 SYSTEM STOP REPLICATED VIEW 可停止所有副本上的刷新。SYSTEM START [REPLICATED] VIEW, START VIEWS
为指定视图或所有可刷新的视图启用周期性刷新。不会立即触发刷新。 如果视图位于 Replicated 或 Shared database 中，START VIEW 会撤销 STOP VIEW 的效果，START REPLICATED VIEW 会撤销 STOP REPLICATED VIEW 的效果。START VIEW 还会撤销 PAUSE VIEW 的效果。
SYSTEM PAUSE VIEW, PAUSE VIEWS
禁用指定视图或所有可刷新的视图的周期性刷新。 与SYSTEM STOP VIEW 不同，SYSTEM PAUSE VIEW 不会中断已在进行的刷新：当前正在运行的刷新会正常完成，只会阻止后续刷新。
可使用 SYSTEM START VIEW 或 SYSTEM START VIEWS 恢复。
暂停状态在 server 重启后不会保留。重启后，视图将恢复为其配置的刷新计划。
在 Replicated 或 Shared 数据库中，
SYSTEM PAUSE VIEW 仅影响当前副本。SYSTEM REFRESH VIEW
立即触发对指定视图的一次计划外刷新。SYSTEM WAIT VIEW
等待正在进行中的刷新完成。如果当前没有刷新在运行，则会立即返回。如果最近一次刷新尝试失败，则会报错。 可在创建新的可刷新materialized view 后 (不带 EMPTY 关键字) 立即使用，以等待初始刷新完成。 如果该视图位于 Replicated 或 Shared database 中，且刷新正在另一副本上运行，则会等待该刷新完成。SYSTEM CANCEL VIEW
如果当前副本上的指定视图正在刷新，则中断并取消该刷新。否则，不执行任何操作。管理后台活动
用于控制单个表或服务器上所有此类表后台活动的引擎无关命令，涵盖：- 可刷新materialized view (定期刷新) ；以及
- 持续从外部来源消费数据的流式表引擎：Kafka、RabbitMQ、NATS、S3Queue 和 AzureQueue。
SYSTEM ... VIEW 命令的别名。因此，SYSTEM STOP [db.]name 的行为与 SYSTEM STOP VIEW [db.]name 完全相同，其他命令也同样如此。
按表形式和通配符形式对没有后台活动的表处理方式不同。按表形式 (SYSTEM STOP [db.]table) 中，如果指定的表既不是流式引擎，也不是可刷新materialized view，则会抛出错误。通配符形式会静默跳过此类表，因此始终可安全运行。
STOP 和 CANCEL 会尽快中断消费。对于 Kafka、RabbitMQ 和 NATS，它们会停止从来源读取数据，但不会中断已开始的插入：正在写入 materialized view 的块仍会完成并提交。S3Queue 和 AzureQueue 会在同一管道中读取和插入数据。启用去重 (默认) 时，插入也会被取消，文件会在之后重新处理。禁用去重时，为避免重复行，正在处理的批次会完成并提交 (与上述引擎相同) 。已读取但尚未提交的数据会在之后再次消费，因此不会丢失数据；但核心 NATS (不含 JetStream) 例外，它无法重新投递，会丢弃这些数据。
PAUSE 不会中断正在进行的插入，因此通常不会导致数据丢失。核心 NATS 是例外：暂停会停止消费，并丢弃已接收但尚未插入的消息，而核心 NATS 无法重新投递这些消息。
这些状态不会在服务器重启后保留。重启后，可刷新视图会恢复按配置计划刷新，流式引擎会恢复消费。
SYSTEM STOP
停止后台活动并使其保持停止状态：中断当前正在运行的操作，在执行SYSTEM START 前不再运行任何操作。等同于 PAUSE + CANCEL。
SYSTEM START
恢复活动，撤销之前执行的SYSTEM STOP 或 SYSTEM PAUSE。不会中断任何活动。
SYSTEM PAUSE
阻止新的后台活动，但允许当前正在运行的操作完成。SYSTEM CANCEL
仅中断当前正在进行的活动，不会阻止后续活动——表仍会按计划继续刷新或消费。如果当前没有正在进行的活动，则不执行任何操作。SYSTEM REFRESH
在计划之外额外运行一个周期。对于流式表，即使表已停止或暂停，也会立即执行一次。对于可刷新materialized view，其行为与SYSTEM REFRESH VIEW 相同：如果该 view 已停止，会记住此次刷新请求，并在 SYSTEM START 将其恢复后执行一次。
特权
每条命令都需要相应目标引擎的特权：可刷新materialized view 需要SYSTEM VIEWS，流式表需要 SYSTEM STREAMING ENGINES。两者均为 SYSTEM BACKGROUND 的子项，因此授予 SYSTEM BACKGROUND 后，便可控制所有此类表的后台活动。ALL BACKGROUND 形式仅适用于用户有权控制的表，其他表将被静默跳过。
SYSTEM FLUSH OBJECT STORAGE QUEUE
阻塞执行，直到指定文件被给定的 S3Queue 或 AzureQueue 表处理完成，或永久失败为止。如果该文件已处理完成，则会立即返回。如果该文件已永久失败 (即所有重试都已耗尽) ，则会引发错误。SYSTEM ENABLE|DISABLE FAILPOINT
failpoint 是服务器代码中的命名位置，可在这些位置按需注入故障 (错误、延迟或暂停当前执行线程) 以用于测试。system.fail_points 表中列出了所有 failpoint 及其当前状态。
SYSTEM ENABLE FAILPOINT 用于启用单个 failpoint；SYSTEM DISABLE FAILPOINT 则将其禁用，并恢复所有阻塞在该 failpoint 上的线程，若该 failpoint 此前并未启用，则该语句为空操作。
SYSTEM DISABLE ALL FAILPOINTS 一次性禁用全部 failpoint，并恢复所有阻塞在可暂停 failpoint 上的线程。该语句不接受名称参数，且具有幂等性，因此测试框架可借助它将服务器恢复到不注入任何故障的状态，而无需知道上一个测试启用了哪些 failpoint。在不支持 failpoint 的构建版本上，该语句会执行成功，但不产生任何效果。
SYSTEM WAIT FAILPOINT ... PAUSE 会持续阻塞，直到有线程在指定的可暂停 failpoint 上暂停 (或该 failpoint 被禁用) ；... RESUME 会持续阻塞，直到被暂停的线程恢复运行；SYSTEM NOTIFY FAILPOINT 则在不禁用 failpoint 的前提下恢复被暂停的线程。
failpoint 属于节点本地状态，因此上述语句均不接受 ON CLUSTER。所有这些语句都需要 SYSTEM FAILPOINT 特权。