在数据库架构中，大查询队列（Large Query Queue）是一种资源隔离机制，专门应对那些需要长时间运行、消耗大量系统资源的分析类（AP）任务。
当混合负载（HTAP）或多用户共享环境运行时，面对既要处理秒级响应的交易类（TP）操作（如在线支付），又要执行复杂分析的报表类查询，OceanBase的智能调度系统会启动流量管控策略：将实时性要求高的TP请求引导至快速通道，同时为AP大查询规划专属"资源隔离带"——即大查询队列，确保两类负载既不互相争抢资源，又能根据系统负载动态调整执行优先级。
OceanBase 的这种设计让关键交易链路可在毫秒级完成，同时允许分析任务“错峰执行”，从根源上解决业务卡顿、超时等问题。
本文将重点介绍 OceanBase 的大查询队列以及 OceanBase 中 SQL 限流的常用方法。
一、大查询的判定标准与识别方法
在限制大查询的资源占用时，首要任务是判定 SQL 语句是否属于大查询。在 OceanBase 4.x 版本中，存在一个集群级配置项，large_query_threshold 其默认值为 5 秒。
对于首次执行的 Query，由于无法预先估算其执行时间，系统将默认其为非大查询。而当同一 Query 再次执行时，得益于 Plan Cache 中已缓存的查询计划，系统会依据缓存中该 Query 的历史平均执行时间，来判断其是否属于大查询。
二、多维管控：大查询的资源限制策略
在 OceanBase 4.x 版本中，当 Query 被判定为大查询后，系统会将其直接移入大查询队列进行重试，并释放当前占用的工作线程。
大查询拥有独立的线程组负责调度执行，该线程组与普通工作线程组处于对等地位，就像数据库系统为大查询专门开辟了一条 “非机动车道”，使其与常规查询在不同的资源路径上并行处理。
大查询队列中的 Query 执行资源受配置项 large_query_worker_percentage （默认值 30%）调控。这一机制类似于为大查询划分独立的资源组，将该组内可使用的 CPU 计算资源限制在总资源的 30%，以此实现对大查询资源占用的精准管控。
三、大查询实战：两大技巧缓解资源争用
1.如果多个首次执行的大查询突然出现，并占用全部普通工作线程时怎么办？
这种情况可通过终止数据库会话（Kill Session）并重新连接的方式缓解。这是因为终止会话后，Plan Cache 仍会保留未执行完毕的 Query 的执行计划及历史执行时间记录。重新连接会话后，系统就能在编译阶段基于 Plan Cache 中的信息预判这些查询属于大查询，将其直接排入大查询队列处理，从而避免对普通工作线程的占用，保障系统资源的合理分配与高效利用。
2.PX 线程如何限制资源占用？
PX 线程（并行执行工作线程）拥有独立的线程组，其执行过程不受大查询队列的限制，大查询队列仅对普通工作线程组产生影响。需要特别说明的是，大查询资源分配遵循动态机制：当系统中无小查询运行时，大查询可占用全部普通工作线程组资源；只有在大查询和小查询并存的情况下， large_query_worker_percentage 配置项设定的默认 30% 资源比例限制才会生效。
这一设计逻辑在于，并行执行的本质是通过调用更多资源实现查询加速，若再通过大查询队列施加限制，这就和并行执行的目标相悖。因此，如需对 PX 线程进行资源限制与隔离，需要借助资源组（resource group）机制完成精细化管控。
关于资源组的详细内容，可参考官方文档：
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001576738
四、SQL 层控制：OceanBase 的限流实现
最后，给大家介绍几个 OceanBase 中与 SQL 限流相关的功能：
1.使用文本限流
如果需要限制某类 SQL 请求的执行流量，可通过创建 Outline，并添加 /*+max_concurrent(N)*/ 这个Hint 实现。其中，N 代表某类 Query 同时可执行的请求数量。实际上，该限制针对某类执行计划同时执行的请求个数 。
语法如下：
CREATE [OR REPLACE]OUTLINE outline_nameON stmt [TO target_stmt];
举个例子：
create table t1(c1 int, c2 int);-- ? 表示通配符，限制这类请求个数最多为 0create outline ol_1 onselect /*+max_concurrent(0)*/ *from t1where c1 = 1 and c2 = ?;-- 执行失败select *from t1where c1 = 1 and c2 = 0;ERROR 5268 (HY000): SQL reach max concurrent num 0-- 执行失败select *from t1where c1 = 1 and c2 = 1;ERROR 5268 (HY000): SQL reach max concurrent num 0-- 执行成功select *from t1where c1 = 12345 and c2 = 2;Empty set (0.01 sec)
2、模糊限流
CREATE [OR REPLACE]FORMAT OUTLINE outline_nameON format_stmt [TO format_target_stmt]
在模糊限流语法中， format_stmt 表示归一化后的 SQL。其归一化规则如下：
常量参数归一化：对 SQL 语句中的常量参数进行标准化处理
大小写统一：将 SQL 语句中的字符统一转换为大写形式
空白符忽略：忽略空格、换行符等非语法定义的符号差异
in 表达式处理：对
in表达式进行归一化操作
obclient>selectstatement_digest_text('select * fromt1 where c1 in (1, 2) and c2 = 3');result : SELECT * FROM T1 WHERE C1 IN (...) AND C2 = ?1 row in set (0.00 sec)
举个例子：
-- 创建 format outlinecreate format outline fmt_otlonselect /*+max_concurrent(0)*/ *from t1where c1 in (?, ?) and c2 = ?;-- 执行失败select *from t1where c1 in (1)and c2 = 2;ERROR 5268 (HY000): SQL reach max concurrent num 0-- 执行失败select *from t1where c1 in (1, 2)and c2 = 3;ERROR 5268 (HY000): SQL reach max concurrent num 0-- 执行失败select *from t1where c1 in (1, 2, 3)and c2 = 4;ERROR 5268 (HY000): SQL reach max concurrent num 0
OceanBase 的大查询队列机制类似“交通信号灯”，本质上是通过资源分级管控与负载类型感知，在有限的硬件资源下实现业务价值最大化——让高频交易“快如闪电”，让复杂分析“行稳致远”。它不仅解决 TP/AP 混部场景下的资源争抢难题，更通过自适应限流、弹性线程组等技术，为高并发、多模态的业务场景提供稳定性保障。
2025 OceanBase 开发者大会将于 5 月 17 日 在广州举行，本届大会以「当 SQL 遇见 AI」为主题，将重磅发布面向 AI 时代的一体化产品矩阵，并分享 TP、AP、KV 及 AI 能力的最新实践成果。欢迎大家扫码，报名参会！
