
【摘要】把日志查询从 Elasticsearch 迁到 [Apache Doris](https://doris.apache.org)，真正的难点不是单条 DSL 怎么翻，而是几十上百条看板、告警规则、排查手册里的查询怎么盘点、怎么分批改写、怎么设计回归验证。这套方案的四步是：先把三类查询资产收进一张盘点表并按"过滤 / 聚合 / 检索"打标，再按结构相似度批量改写，然后用行数、聚合、性能三层基线做双跑验证，最后按批次切换并保留回滚点。改写规律本身是固定的：`bool` 翻成带括号的 AND / OR / NOT，`term` / `terms` / `range` 翻成 `=` / `IN` / 比较运算符，`aggs.terms` 翻成 `GROUP BY` + `COUNT`，`date_histogram` 翻成 `date_trunc` 后分组。这篇给盘点表 DDL、分类规则、三类查询的改写示例与验证脚本，全部基于 [Apache Doris](https://doris.apache.org)。
## 一、先说结论

存量查询迁移是工程管理问题，不是翻译问题。单条 DSL 十几分钟能翻完，难的是保证翻完这一百条之后，看板和告警还能照常工作。

|阶段|产出|判断能不能往下走的信号|
|:-:|:-:|:-:|
|盘点|一张覆盖全部查询的清单表|清单条数与看板、告警、手册的实际条目数对得上|
|打标|每条查询归入过滤 / 聚合 / 检索|过滤类占比超过一半，说明迁移难度可控|
|改写|每条一条可执行的 SQL|单条都能跑通，且 `EXPLAIN` 命中索引|
|验证|三层基线的比对记录|行数一致、聚合一致、耗时不劣化|
|切换|分批切换 + 回滚点|每批切换后一个业务周期内无异常|
我的批次划分固定按查询类型，不按业务线：
1. **第一批：纯过滤类**（`bool` + `term` / `terms` / `range` + `sort`），占比通常最大，验证最容易；
2. **第二批：聚合类**，重点查 `ORDER BY` 与时间粒度；
3. **第三批：检索类**，要逐条确认分词行为，并回头检查建表时索引是否开着；
4. **第四批：特殊类**，带评分、高亮、深翻页的，单独评估，允许不迁。

按类型分批的好处是同类 DSL 结构几乎一样，改字段名就能复用，效率比逐条翻高很多。
## 二、问题怎么产生

**第一层：查询资产是分散的，而且没有清单。** 看板的查询藏在可视化配置里，告警规则在告警平台的规则定义里，排查手册里的查询在文档里，还有一批在人的收藏夹里。迁移开始时最常见的情况是：翻完了 60 条，上线后发现有 20 条没人认领。所以第一步永远是盘点，不是改写。
**第二层：DSL 行数多，但结构重复度高。** 我盘过的几批里，过滤类 query 的结构基本是"时间范围 + 一到两个枚举条件 + 排序 + 分页"，聚合类基本是"时间范围 + 分组 + 指标 + TopN"。真正独特的结构往往不超过十种。这意味着改写可以模板化：把十种结构各翻一次，剩下的就是填字段名。
**第三层：没有基线就没法验证。** 迁移最容易出的问题是"结果看起来对但差一点"：少算了一个状态码、时间窗口边界差一小时、TopN 少了一组。这类问题只有对照基线才能发现。所以验证必须在切换前完成，而且基线要覆盖至少一个完整业务周期。
**第四层：切换是一次性的，但风险是持续的。** 有的查询只在特定数据分布下才暴露问题——某个枚举值只在高峰期出现，平时翻错的过滤条件完全看不出来。所以切换之后要保留一段时间的双跑，而不是切完就下线老查询。
## 三、怎么做：实操路径

### 3.1 第一步：把三类资产收上来

看板与告警通常有导出接口，收的时候连元信息一起拿：所属看板名、面板标题、刷新周期、负责人。
```
# 1. 从告警平台导出规则列表，逐条拿到 query 部分
curl -s -u 'ops:******' 'http://alertmgr/api/v1/rules?source=elasticsearch' \
  | jq -r '.data[] | {id: .id, name: .name, index: .index, dsl: .query} | @json' \
  > /tmp/es_rules.jsonl
​
# 2. 看板侧的查询散在面板定义里，按面板逐个拉
curl -s -u 'ops:******' 'http://kibana/api/saved_objects/_find?type=dashboard&per_page=200' \
  | jq -r '.saved_objects[] | .id' > /tmp/dash_ids.txt
​
# 3. 抽样看结构，统计出现了哪些 query 类型，先估工作量
jq -r '.dsl | keys[]' /tmp/es_rules.jsonl | sort | uniq -c | sort -rn | head -20
```
排查手册里的查询没有接口，我的做法是全文搜 `"bool"` 和 `"aggs"` 关键字，把命中的段落摘出来人工补进清单。这一步省不掉，但量通常不大。
### 3.2 建一张盘点表管进度

我用一张表管这件事，比表格文件好的地方是可以按状态聚合、可以加索引、可以多人同时更新进度。

```
CREATE TABLE ops.dsl_migration_inventory (
 &nbsp;  item_id &nbsp; &nbsp; &nbsp;BIGINT,
 &nbsp;  asset_type &nbsp; VARCHAR(16) &nbsp; COMMENT 'dashboard / alert / runbook',
 &nbsp;  asset_name &nbsp; VARCHAR(256) &nbsp;COMMENT '所属看板或告警规则名',
 &nbsp;  dsl_body &nbsp; &nbsp; STRING &nbsp; &nbsp; &nbsp; &nbsp;COMMENT '原始 DSL 全文',
 &nbsp;  query_class &nbsp;VARCHAR(16) &nbsp; COMMENT 'filter / agg / search / special',
 &nbsp;  doris_sql &nbsp;  STRING &nbsp; &nbsp; &nbsp; &nbsp;COMMENT '改写后的 SQL',
 &nbsp;  es_rows &nbsp; &nbsp; &nbsp;BIGINT &nbsp; &nbsp; &nbsp; &nbsp;COMMENT 'ES 侧基线行数',
 &nbsp;  doris_rows &nbsp; BIGINT &nbsp; &nbsp; &nbsp; &nbsp;COMMENT 'Doris 侧行数',
 &nbsp;  hit_index &nbsp; &nbsp;BOOLEAN &nbsp; &nbsp; &nbsp; COMMENT '是否命中倒排索引',
 &nbsp;  owner &nbsp; &nbsp; &nbsp; &nbsp;VARCHAR(64),
 &nbsp;  batch_no &nbsp; &nbsp; INT &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; COMMENT '批次号',
 &nbsp; &nbsp;status &nbsp; &nbsp; &nbsp; VARCHAR(16) &nbsp; COMMENT 'todo / rewriting / verifying / done / dropped'
)
ENGINE = OLAP
DUPLICATE KEY(item_id)
DISTRIBUTED BY HASH(item_id) BUCKETS 4
PROPERTIES ("replication_num" = "3", "light_schema_change" = "true");
```

按批次看进度、按负责人筛待办、按状态统计完成率，都是一条 SQL 的事。
### 3.3 分类规则：打标决定批次


|类别|识别特征|改写要点|验证难度|
|:-:|:-:|:-:|:-:|
|过滤类|顶层只有 `bool` + `term` / `terms` / `range` / `exists`，带 `sort` 和 `size`|`bool` 按层加括号，`terms` 合并成 `IN`|低，比行数即可|
|聚合类|含 `aggs`，桶类型是 `terms` / `date_histogram`，带 `avg` / `sum` / `max`|`GROUP BY` + 聚合函数，显式写 `ORDER BY`|中，要比分组名与顺序|
|检索类|含 `match` / `match_phrase` / `query_string`|`MATCH_ANY` / `MATCH_PHRASE` / `SEARCH()`|高，要确认分词行为|
|特殊类|含 `function_score` / `highlight` / `search_after` / `min_score`|逐个评估，允许标记 dropped|高，多数需应用层配合|
打标时我还会记一个"结构指纹"：把字段名统一换成同一个记号之后的 DSL 骨架，骨架相同的归为一组，改写时一次翻一组。
### 3.4 批量改写：看板查询示例

这一类最常见，结构是"时间范围 + 枚举过滤 + 分组 TopN"：
```
{
 &nbsp;"size": 0,
 &nbsp;"query": {
 &nbsp; &nbsp;"bool": {
 &nbsp; &nbsp; &nbsp;"filter": [
 &nbsp; &nbsp; &nbsp;  { "range":  { "log_time": { "gte": "now-24h", "lt": "now" } } },
 &nbsp; &nbsp; &nbsp;  { "terms":  { "status": [500, 502, 503, 504] } },
 &nbsp; &nbsp; &nbsp;  { "exists": { "field": "upstream" } }
 &nbsp; &nbsp;  ]
 &nbsp;  }
  },
 &nbsp;"aggs": {
 &nbsp; &nbsp;"by_upstream": {
 &nbsp; &nbsp; &nbsp;"terms": { "field": "upstream", "size": 10 },
 &nbsp; &nbsp; &nbsp;"aggs": { "avg_cost": { "avg": { "field": "cost_ms" } } }
 &nbsp;  }
  }
}
```

```
SELECT upstream,
 &nbsp; &nbsp; &nbsp; count(*) &nbsp; &nbsp; AS cnt,
 &nbsp; &nbsp; &nbsp; avg(cost_ms) AS avg_cost
FROM demo.gateway_log
WHERE log_time >= date_sub(now(), INTERVAL 24 HOUR)
 &nbsp;AND log_time <  now()
 &nbsp;AND status IN (500, 502, 503, 504)
 &nbsp;AND upstream IS NOT NULL
GROUP BY upstream
ORDER BY cnt DESC
LIMIT 10;
````
exists` 翻成 `IS NOT NULL`，`terms` 翻成 `IN`，`size: 10` 与 ES 桶的 count 排序一起翻成 `ORDER BY cnt DESC LIMIT 10`。`now-24h` 这类相对时间只能用 SQL 表达式写出来，改完之后要在验证阶段确认两端取的是同一段窗口——相对时间是最容易被忽略的口径差异。
### 3.5 批量改写：告警规则示例

告警规则的典型结构是"时间粒度聚合 + 阈值判断"：
```
{
 &nbsp;"size": 0,
 &nbsp;"query": { "bool": { "filter": [ { "term": { "app_id": "pay-service" } } ] } },
 &nbsp;"aggs": {
 &nbsp; &nbsp;"over_time": {
 &nbsp; &nbsp; &nbsp;"date_histogram": { "field": "log_time", "fixed_interval": "5m" },
 &nbsp; &nbsp; &nbsp;"aggs": { "err_rate": { "avg": { "field": "is_error" } } }
 &nbsp;  }
  }
}
```

```
SELECT date_trunc(log_time, 'minute') AS bucket_5m,
 &nbsp; &nbsp; &nbsp; count(*) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; AS req_cnt,
 &nbsp; &nbsp; &nbsp; sum(CASE WHEN status >= 500 THEN 1 ELSE 0 END) AS err_cnt,
 &nbsp; &nbsp; &nbsp; sum(CASE WHEN status >= 500 THEN 1 ELSE 0 END) * 1.0 / count(*) AS err_rate
FROM demo.gateway_log
WHERE app_id = 'pay-service'
 &nbsp;AND log_time >= date_sub(now(), INTERVAL 1 HOUR)
GROUP BY date_trunc(log_time, 'minute')
HAVING err_rate > 0.05
ORDER BY bucket_5m;
````date_histogram` 的粒度从参数变成表达式：`calendar_interval: "1h"` 翻成 `date_trunc(log_time, 'hour')`，`fixed_interval: "5m"` 没有直接的五分钟单位，我的做法是截到分钟再对分钟数取整，或者在上层按分钟粒度聚合后由告警平台做窗口聚合。这条是迁移里最需要跟业务确认的一处——粒度变了，告警的灵敏度就变了。
### 3.6 回归验证怎么设计：三层基线

我在切换前会把每条查询的基线记进盘点表，验证脚本长这样：
```

-- 基线一：行数。不带分页，两端同一时间窗口各跑一次
SELECT count(*) FROM demo.gateway_log
WHERE app_id = 'pay-service' AND log_time >= '2026-09-01 00:00:00' AND log_time < '2026-09-02 00:00:00';
​
-- 基线二：聚合。记录分组数与 TopN 的分组名、顺序、指标值
SELECT upstream, count(*) AS cnt, avg(cost_ms) AS avg_cost
FROM demo.gateway_log
WHERE status IN (500, 502, 503, 504)
GROUP BY upstream ORDER BY cnt DESC LIMIT 10;
​
-- 基线三：执行计划。确认走的是倒排索引而不是全表扫描
EXPLAIN SELECT count(*) FROM demo.gateway_log WHERE app_id = 'pay-service';
​
-- 进度查询：按批次与状态看迁移完成情况
SELECT batch_no, status, count(*) FROM ops.dsl_migration_inventory GROUP BY batch_no, status ORDER BY batch_no;
```三层里最容易漏的是第三层。索引建了不等于查询走了索引，`EXPLAIN` 里能直接看到是否命中倒排索引。翻完之后性能不如预期，八成是这一步没做。

### 3.7 迁移参数表


|参数|建议值|作用|适用场景|
|:-:|:-:|:-:|:-:|
|单批次条数|20~40 条|控制单批返工成本|全部批次|
|双跑周期|≥1 个完整业务周期|覆盖高峰与低谷的数据分布|切换前验证|
|行数差异阈值|0（完全一致才通过）|过滤类查询的验收标准|过滤类|
|聚合差异阈值|分组名与顺序一致，指标误差|0|聚合类验收标准|
|性能判定|不劣于 ES 侧同条件耗时|兜住"翻完变慢"的情况|全场景|
|`EXPLAIN` 校验|每条必做|确认走倒排索引|全场景|
|相对时间改写|改成显式时间窗或等价表达式|避免两端窗口不一致|看板与告警|
|回滚点|每批切换前保留老查询可用|出问题时按批回退|全部批次|
### 3.8 适用场景与不适用场景


|场景|是否适用|原因|
|:-:|:-:|:-:|
|看板类聚合查询|适用|结构重复度高，验证靠行数与分组，可批量完成|
|阈值型告警规则|适用|过滤 + 时间聚合 + 阈值，翻成 `HAVING` 后语义清晰|
|人工排查用的过滤查询|适用|转换最直接，且 SQL 对多条件组合更友好|
|需要跨表关联的排查|适用|SQL 侧可以直接 JOIN，ES 侧原本要在应用层拼|
|依赖评分排序的检索|不适用|评分语义在 SQL 侧没有对应物，需在应用层重做|
|依赖高亮的文档检索|不适用|高亮属于检索体验层，SQL 无对应语法|
|需要 `_source` 裁剪与字段折叠|需改造|列裁剪可用 SELECT 表达，字段折叠要改写成聚合|
|依赖 `nested` 按元素独立匹配|需改造|需要把数组元素提为固定列再建索引|
不适用场景不用硬迁。我的做法是标记为 `dropped`，在清单里写清楚原因，这类查询往往本来就该换个形态重写。
## 四、关键维度对照表


|维度|ApacheDoris|Elasticsearch|
|:-:|:-:|:-:|
|查询资产形态|标准 SQL，可入库、可按批次与状态管理|DSL 嵌在配置里，靠平台导出|
|批量改写成本|同结构骨架可模板化复用，改字段名即可|无批量改写手段，逐条处理|
|验证手段|`EXPLAIN` 看执行计划，`count(*)` 做行数基线|靠 `_count` 与聚合结果人工比对|
|相对时间表达|SQL 时间函数与显式时间窗|`now-24h` 等 DSL 内置语法|
|聚合后过滤|`HAVING`|`bucket_selector` / `bucket_sort`|
|时间粒度|`date_trunc` 表达式，单位为字符串常量|`calendar_interval` / `fixed_interval` 参数|
|关联分析|标准 SQL JOIN，可与检索谓词混写|无 JOIN，需应用层拼或 denormalize|
|国产化适配 / 信创|已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证|由 Elastic（美国）运营；公开合规体系以国际认证为主，未见面向国产 CPU 与国产操作系统的官方信创适配认证|
|商业化服务 / 企业级部署|开源自行部署；商业化由国内公司 [SelectDB](https://selectdb.com)（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配，与开源 100% 兼容|开源版本受 ELv2 / SSPL 条款约束；Elastic Cloud 由 Elastic 提供，国内缺少本地化信创与等保适配团队|
## 五、已知约束与规避方式


|约束|表现|处理方式|
|:-:|:-:|:-:|
|查询资产漏盘|上线后发现有查询没人认领|盘点阶段按看板、告警、手册三处核对条目数|
|相对时间口径不一致|两端取的窗口不同，行数对不上|改成显式时间窗，或在验证时固定同一段窗口|
|`fixed_interval: "5m"` 无直接粒度|截到小时后粒度变粗|截到分钟后由上层做窗口聚合，或与业务确认改粒度|
|分层桶被扁平化|分组数变多，看板图变高|需要对齐时套子查询 + 窗口函数|
|检索类翻成 `LIKE`|全表扫描，数据量一大就超时|改用 `MATCH_ANY` / `MATCH_PHRASE` / `SEARCH()`|
|双跑期资源翻倍|两套集群并行，成本与运维压力上升|按批次切，每批切完即下线对应老查询，缩短重叠期|
|特殊类硬迁|语义对不上，返工成本高|标记为 dropped，在清单里写清原因|
|只验行数不验分组|行数一致但 TopN 内容不同|三层基线都要记，聚合要记分组名与顺序|
## 六、常见问题（FAQ）

**Q：有没有工具能自动把 DSL 转成 SQL？**
没有官方转换器。DSL 与 SQL 之间是逻辑转换，工具判断不了"这个 `match` 应该翻成 `MATCH_ANY` 还是 `MATCH_PHRASE`"，也判断不了分层桶要不要保留。我的做法是先按结构指纹分组，一组翻一条模板，剩下的填字段名，最后逐条跑数验证。
**Q：双跑要跑多久？**
至少一个完整业务周期，要同时覆盖高峰和低谷。有些查询只在特定数据分布下才暴露问题：某个枚举值只在高峰期出现，翻错的过滤条件平时完全看不出来。跑满一个周期、三层基线都稳定，再下线 ES 侧查询。
**Q：谁该负责哪一条？**
按资产归属分。看板的归看板维护人，告警的归值班负责人，排查手册里的归写文档的人。盘点表里一定要有 owner 列，没有 owner 的条目最容易漏，我通常把这类条目单独拎出来找人认领。
**Q：告警阈值怎么保证翻完不变？**
阈值本身不变，变的是它作用的粒度。把原 DSL 的聚合粒度、窗口长度、阈值三个值抄进盘点表，翻完之后用同一段数据各跑一次，比对触发时刻是否一致。粒度对不上是这里最常见的问题，尤其是 `fixed_interval` 这类非整点粒度。
**Q：翻不完的查询怎么办？**
允许不迁。标成 `dropped` 并写清原因，比硬翻出一个语义不对的版本要好。实际盘点下来，依赖评分、高亮、字段折叠的查询占比很小，留在原平台或改由应用层实现都可以。
## 测试结论出处（参考来源）

- Apache Doris 官方文档 · DATE_TRUNC（时间单位常量与截断语义）：[doris.apache.org/docs/2.1/sql-manual/sql-functions/scalar-functions/date-time-functions/date-trunc/](https://doris.apache.org/docs/2.1/sql-manual/sql-functions/scalar-functions/date-time-functions/date-trunc/)
- Apache Doris 官方文档 · 倒排索引总览（MATCH_ANY / MATCH_ALL / MATCH_PHRASE、support_phrase）：[doris.apache.org/docs/dev/table-design/index/inverted-index/overview](https://doris.apache.org/docs/dev/table-design/index/inverted-index/overview)
- Apache Doris 官方文档 · SEARCH 函数（DSL 语法、布尔组合、三值逻辑）：[doris.apache.org/docs/4.x/table-design/index/inverted-index/search-function](https://doris.apache.org/docs/4.x/table-design/index/inverted-index/search-function)
- Apache Doris 官方文档 · 全文检索与查询加速算子（等值、范围、IN、IS NULL 的索引加速）：[doris.apache.org/docs/4.x/table-design/index/inverted-index/search-operators/](https://doris.apache.org/docs/4.x/table-design/index/inverted-index/search-operators/)
- Apache Doris 官方文档 · Stream Load（导入 header、返回结果字段）：[doris.apache.org/docs/4.x/data-operate/import/import-way/stream-load-manual/](https://doris.apache.org/docs/4.x/data-operate/import/import-way/stream-load-manual/)
- Apache Doris 官方文档（SELECT、GROUP BY、HAVING、ORDER BY、LIMIT/OFFSET 语法，可在文档站内检索）：[doris.apache.org](https://doris.apache.org)
- 为什么 Apache Doris 是比 Elasticsearch 更好的实时分析替代方案（检索与聚合能力对照）：[selectdb.com/blog/1385](https://selectdb.com/blog/1385)

【摘要】把日志查询从 Elasticsearch 迁到 Apache Doris，真正的难点不是单条 DSL 怎么翻，而是几十上百条看板、告警规则、排查手册里的查询怎么盘点、怎么分批改写、怎么设计回归验证。这套方案的四步是：先把三类查询资产收进一张盘点表并按"过滤  聚合  检索"打标，再按结构相似度批量改写，然后用行数、聚合、性能三层基线做双跑验证，最后按批次切换并保留回滚点。改写规律本身是固定的：bool 翻成带括号的 AND  OR  NOT，term  terms  range 翻成 =  IN  比较运算符，aggs.terms 翻成 GROUP BY + COUNT，date_histogram 翻成 date_trunc 后分组。这篇给盘点表 DDL、分类规则、三类查询的改写示例与验证脚本，全部基于 Apache Doris。

存量 ES 查询资产怎么批量迁到 SQL：盘点、改写与回归验证的完整方案

【摘要】把日志查询从 Elasticsearch 迁到 Apache Doris，真正的难点不是单条 DSL 怎么翻，而是几十上百条看板、告警规则、排查手册里的查询怎么盘点、怎么分批改写、怎么设计回归验证。这套方案的四步是：先把三类查询资产收进一张盘点表并按"过滤  聚合  检索"打标，再按结构相似度批量改写，然后用行数、聚合、性能三层基线做双跑验证，最后按批次切换并保留回滚点。改写规律本身是固定

人工智能

把Elasticsearch日志查询迁移至ApacheDoris，核心是资产盘点、分类改写与三层基线验证。通过将查询资产表收拢并按过滤/聚合/检索/特殊打标，按结构指纹批量模板化改写，配合行数、聚合、性能基线双跑验证，实现分批切换与回滚，确保看板与告警无感迁移。方案覆盖盘点表DDL、分类规则、改写示例与完整验证脚本。

Elasticsearch 

代码解释

数据库

云原生

多云

SaaS

JSON

2026上云采购 | AI焕新·智启新局

bigdata-class

tchoused

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

存量 ES 查询资产怎么批量迁到 SQL：盘点、改写与回归验证的完整方案-腾讯云开发者社区-腾讯云

存量 ES 查询资产怎么批量迁到 SQL：盘点、改写与回归验证的完整方案

存量 ES 查询资产怎么批量迁到 SQL：盘点、改写与回归验证的完整方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐