一、引言：从 KWDB 3.0 到 3.1，我们完成了什么

2025 年 11 月，KWDB 3.0 发布会上的圆桌讨论中，我曾表达过一个观点：单一的时序数据库几乎能满足物联网场景应用，但设备关联信息往往存放在关系型数据库中——需要跨模融合。真正让时序数据产生业务价值的，恰恰是这种"一个 SQL 打通时序与关系"的体验。

2026 年初，我在《OpenClaw+Docker+KWDB3.1》（原文链接：https://mp.weixin.qq.com/s/LU9Wr-0ISwxANN3iBf9lng）一文中，首次用 OpenClaw 完成 KWDB 3.1.0 的容器化部署，建起了监控点、车辆信息、过车流水三张表，用 100 万条模拟数据验证了跨模关联查询的能力。文章发布后，社区陆续收到不少反馈，集中在"建表之后具体怎么用""异常检测怎么做""慢 SQL 如何优化"这类实操层面。

KWDB 社区显然也听到了这些声音。从 2026 年 2 月发布的 3.1.0 版本开始，官方在查询性能、数据压缩、存储过程、运维命令等多个维度做了大幅增强；与此同时，9 个 Agent Skill 也在持续迭代，覆盖从 Schema 设计到故障诊断的完整生命周期。

本文则在此基础上更进一步——不再重复部署过程，而是直接连接已有的 KWDB 3.1.0 环境，围绕一个**省级公安交通卡口**的真实业务场景，系统体验 KWDB 3.1.0 的新特性与 Agent Skill 工具链的配合。场景设定：某省 10,000 个卡口监控点，日均过车记录 100 万条，涉及 100,000 辆机动车，需要解决跨模查询、异常分析、性能审查等日常问题。

实测环境信息如下：

| 项目 | 内容 |

|------|------|

| KWDB 版本 | 3.1.0（Build: 2026/02/02 10:31:37） |

| 容器镜像 | registry.cn-hangzhou.aliyuncs.com/kwdb/kwdb:3.1.0 |

| 宿主机 | 10.60.143.102（Docker 运行环境） |

| 数据库 | defaultdb（1 万卡口 + 10 万车辆 + 100 万过车记录） |

| 连接方式 | kwbase sql --insecure --url="postgresql://root@localhost:26257/defaultdb" |

---

二、环境就绪：连接现有 KWDB 3.1.0 容器

部署环节已在《OpenClaw+Docker+KWDB3.1》一文中介绍过，本文不再赘述。此处直接连接已运行的容器环境。

连接命令：

docker exec kwdb3.1-test \
/kaiwudb/bin/kwbase sql \
--insecure \
--url="postgresql://root@localhost:26257/defaultdb"

实测版本信息：

KaiwuDB Version: 3.1.0
Build Time: 2026/02/02 10:31:37
Platform: linux amd64 (x86_64-linux-gnu)
Go Version: go1.21.13
C Compiler: gcc 11.4.0
Build SHA-1: 06c16a1d5cb15cda64acd4dba063e65da894d1e0

查看数据库现状：

SHOW DATABASES;

database_name | engine_type
---------------+-------------
defaultdb | RELATIONAL
postgres | RELATIONAL
system | RELATIONAL

当前 defaultdb 中有三张业务表：

table_name | table_type
----------------+-------------
monitor_location | BASE TABLE -- 1万卡口监控点
traffic_flow | BASE TABLE -- 100万过车记录
vehicle_info | BASE TABLE -- 10万机动车

图 2-1 三张业务表的实体关系

┌─────────────────────┐ ┌──────────────────────┐
│ monitor_location │ │ vehicle_info │
│ (卡口监控点, 1万) │ │ (机动车信息, 10万) │
├─────────────────────┤ ├──────────────────────┤
│ id INT8 PK │ │ id INT8 PK │
│ device_code VARCHAR │ │ plate_no VARCHAR UK │
│ name VARCHAR │ │ vehicle_type VARCHAR │
│ city VARCHAR │ │ register_date DATE │
│ district VARCHAR │ │ created_at TIMESTAMP │
│ latitude DECIMAL │ └──────────────────────┘
│ longitude DECIMAL │ │
│ created_at TIMESTAMP│ │
└──────────┬──────────┘ │
│ device_code │ plate_no
│ │
│ ┌──────────────────────────┘
│ │
▼ ▼
┌───────────────────────┐
│ traffic_flow │
│ (过车流水, 100万) │
├───────────────────────┤
│ id BIGSERIAL PK │
│ plate_no VARCHAR │
│ device_code VARCHAR │
│ pass_time TIMESTAMP │
│ speed DECIMAL(5,2) │
│ direction VARCHAR(10) │
└───────────────────────┘

---

三、数据建模与迁移：kwdb-schema-design + kwdb-data-migration

3.1 kwdb-schema-design：先理解负载，再生成可验证 DDL

**场景**：某省新建一批新能源车专用卡口，需要新增一张"新能源车过车记录"表，要求关联车辆类型、充电状态等字段。

kwdb-schema-design Skill 的核心理念是"先理解负载"，即不盲目生成 DDL，而是先确认负载类型（关系型/时序型/混合型）、字段定义、主键策略和数据保留周期。

以新能源车卡口表为例，Skill 会引导确认以下关键项：

| 确认项 | 建议值 | 说明 |

|--------|--------|------|

| 负载类型 | 混合型 | 过车流水为时序特征，车主信息为关系特征 |

| 主键 | device_code + pass_time | 避免时序场景下自增主键导致的写入热点 |

| 标签字段 | plate_no, vehicle_type | 用于过滤和聚合 |

| 时间字段 | pass_time TIMESTAMPTZ | 带时区，兼容跨时区查询 |

| 保留周期 | 90 天 | 省级卡口数据量庞大，需设置生命周期 |

生成 DDL 后，Skill 提供验证语句：

SHOW CREATE TABLE traffic_flow; SHOW COLUMNS FROM traffic_flow; SHOW INDEX FROM traffic_flow;

KWDB 3.1.0 在建表层面新增了 `IF NOT EXISTS` 语法，避免重复创建报错。实测：

CREATE TABLE IF NOT EXISTS traffic_flow_test (id INT8, speed DECIMAL(5,2));

CREATE TABLE

再次执行同一语句，表已存在但不再报错——这是 3.1.0 相比 3.0.0 的重要改进。

3.2 kwdb-data-migration：异构数据源的确认门设计

**场景**：需要将历史 Oracle 卡口数据迁移到 KWDB，源端包含 MySQL 和 Oracle 两个异构系统。

kwdb-data-migration Skill 通过 KDTS（KaiwuDB Data Transfer Service）REST API 串起完整迁移流程。关键设计是"确认门"——每个关键步骤都需要操作者显式确认，避免自动执行导致的不可逆风险。

迁移前的风险拦截点包括：

- 引擎不匹配：Oracle 的 LONG/LOB 类型需预处理

- 主标签约束：KWDB 时序表要求主标签非空

- 字符集差异：Oracle AL32UTF8 与 KWDB UTF-8 的映射

建议分两步执行：先做 Schema-only 迁移（验证 DDL 转换），再进入数据迁移。这样即使 DDL 有问题，也不会丢失数据。

图 3-1 kwdb-data-migration 确认门流程

┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 1. 参数收集 │───▶│ 2. 兼容性校验 │───▶│ 3. 连接测试 │
└──────────────┘ └──────────────┘ └──────────────┘
│
┌───────────────────────────────────┘
▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 4. 元数据预览 │───▶│ 5. 用户确认 │───▶│ 6. 任务提交 │
└──────────────┘ └──────────────┘ └──────────────┘
│
┌───────────────────────────────────┘
▼
┌──────────────┐ ┌──────────────┐
│ 7. 状态监控 │───▶│ 8. 迁移验收 │
└──────────────┘ └──────────────┘

---

四、查询与分析：kwdb-text2sql-aiot

4.1 kwdb-text2sql-aiot：自然语言到可验证 SQL

**场景**：交警指挥中心接到报案，需要快速回答"过去一小时内在朝阳区卡口，有哪些车速超过 70 km/h 的车辆，记录了什么时间、从哪个卡口通过"。

kwdb-text2sql-aiot Skill 的执行路径：

**第一步**：获取真实 Schema（避免凭空猜字段名）

SHOW TABLES FROM defaultdb;
SHOW COLUMNS FROM traffic_flow;
SHOW COLUMNS FROM monitor_location;
SHOW COLUMNS FROM vehicle_info;

**第二步**：根据问题类型匹配 SQL 规则

该问题涉及时序过滤（pass_time）、条件过滤（speed > 70）、维表关联（monitor_location 过滤 district）——属于"时序 + 关系跨模 JOIN"场景。

**第三步**：生成 SQL 并附带假设清单

-- 查询条件：朝阳区卡口 + 过去1小时 + 车速>70 SELECT t.pass_time, t.device_code, m.name AS location_name, m.district, t.plate_no, t.speed, t.direction FROM traffic_flow t JOIN monitor_location m ON t.device_code = m.device_code WHERE m.district = '朝阳' AND t.pass_time >= NOW() - INTERVAL '1 hour' AND t.speed > 70 ORDER BY t.pass_time DESC;

第三步生成的是"初版 SQL"：在没有中文列注释的条件下，采用保守 JOIN 策略，只关联了 traffic_flow + monitor_location 两个表，遗漏了 vehicle_info 维表。实测验证发现了这一缺陷，修正版补全了 vehicle_info 的关联。

**第四步**：实测验证

kwdb-text2sql-aiot 之所以能生成 JOIN 条件，根源在于它拿到了完整的 information_schema 元信息——这正是它与普通 SQL 编辑器的本质区别：不是靠记忆字段名，而是带着数据库真实结构生成 SQL。元信息查询语句如下。需要说明的是，下表"字段注释"一列在当前实测库中**全部为空**（这正是本次裸测的前提条件），此处列出的是**建议补充后的理想状态**，用于说明列注释对语义映射的作用：

information_schema 元信息是 kwdb-text2sql-aiot 生成 SQL 的必要条件，但仅有元信息还不够——SQL 生成还需要依赖 kwdb-text2sql-aiot Skill 内置的 SQL 模板库和规则路由机制：根据问题类型（时序过滤、维表关联、聚合分析等）匹配对应模板，填入真实表名和字段名，生成可执行 SQL。因此，kwdb-text2sql-aiot 的准确率同时取决于：元信息完整度（列名是否规范）和模板规则覆盖度。

SELECT c.table_name AS 表名, c.column_name AS 列名, c.data_type AS 数据类型, c.column_comment AS 字段注释 FROM information_schema.columns c WHERE c.table_schema = 'defaultdb' ORDER BY c.table_name, c.ordinal_position;

表名 | 列名 | 数据类型 | 字段注释（中文）

-------------------+---------------+-----------+--------------------------------

traffic_flow | plate_no | varchar | 车牌号

traffic_flow | speed | double | 经过速度（km/h）

traffic_flow | pass_time | timestamp | 经过时间

traffic_flow | device_code | varchar | 卡口设备编号

monitor_location | device_code | varchar | 卡口设备编号（外键关联）

monitor_location | district | varchar | 所在行政区

monitor_location | name | varchar | 卡口名称

monitor_location | city | varchar | 所属城市

vehicle_info | plate_no | varchar | 车牌号（外键关联）

vehicle_info | vehicle_type | varchar | 车辆类型

从元信息表可见"朝阳区超速车辆"→ SQL 的映射链路："区/行政区"→ district 列（monitor_location）；"超速"→ speed 列（traffic_flow，"超"即 > 阈值）；"卡口"→ device_code 跨表一致→推断 JOIN 条件；"车牌"→ plate_no 关联 vehicle_info 获取"车辆类型"。标准列名本身已是"机器可读的中文语义"，列名越规范，映射链路越短，准确率越高。

修正版 SQL（补全 vehicle_info 维表）：

SELECT v.plate_no, v.vehicle_type, t.speed, t.direction, m.city, m.district, t.pass_time FROM traffic_flow t JOIN monitor_location m ON t.device_code = m.device_code JOIN vehicle_info v ON t.plate_no = v.plate_no WHERE m.district = '朝阳' AND t.speed > 70 ORDER BY t.pass_time DESC LIMIT 5;

图 4-1 kwdb-text2sql-aiot 执行流程

"过去1小时朝阳区超速车辆"
│
▼
┌─────────────────────────┐
│ ① Schema 获取 │
│ SHOW COLUMNS ... │ 避免字段名猜错
└─────────────────────────┘
│
▼
┌─────────────────────────┐
│ ② 规则匹配 │
│ 时序过滤 + 跨模JOIN │
└─────────────────────────┘
│
▼
┌─────────────────────────┐
│ ③ SQL 生成 │
│ + 字段映射 + 假设清单 │
└─────────────────────────┘
│
▼
┌─────────────────────────┐
│ ④ 写操作请求确认 │
└─────────────────────────┘

kwdb-text2sql-aiot Skill 并非独立的对话框窗口，而是一个可被任意 Skill 或工作流调用的 SQL 生成子模块。其底层依赖 KWDB 官方 SQL 模板库和规则路由机制，kwdb-text2sql-aiot Skill 封装了"Schema 发现 → 规则匹配 → SQL 生成 → 假设说明"的全流程，用户只需提供自然语言描述，Skill 自动完成字段映射并返回可执行 SQL。在没有配置 SQL 模板的场景下，kwdb-text2sql-aiot 也可以手动指定表名和条件进行查询。

4.1.1 能力边界：没有数据治理时靠什么工作

在实测过程中，我特别做了一次"裸测"：在不依赖任何列注释、没有任何业务字典的前提下，纯粹依赖标准 SQL 元信息和 kwdb-text2sql-aiot 内置规则，来验证 text2sql 的实际能力边界。

首先用标准 SQL 查看数据库中实际有哪些表和字段：

SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_schema = 'defaultdb' ORDER BY table_name, ordinal_position;

返回结果如下：

3 张表 19 个字段，没有任何中文列注释。

接下来，执行没有数据治理时的核心查询——"过去一小时内在朝阳区卡口，有哪些车速超过 70 km/h 的车辆，记录了什么时间、从哪个卡口通过"：

SELECT t.pass_time, t.device_code, m.name AS location_name, m.district, t.plate_no, t.speed, t.direction FROM traffic_flow t JOIN monitor_location m ON t.device_code = m.device_code WHERE m.district = '朝阳' AND t.speed > 70 ORDER BY t.pass_time DESC;

实测结果如下：

pass_time | device_code | location_name | district | plate_no | speed | direction
----------------------------+-------------+---------------+----------+----------+-------+------------
2025-01-01 00:16:39+00:00 | DEV_1000 | monitor_1000 | 朝阳 | VN51000 | 78.34 | 东
2025-01-01 00:16:39+00:00 | DEV_3000 | monitor_3000 | 朝阳 | VN53000 | 76.24 | 东
2025-01-01 00:16:39+00:00 | DEV_8000 | monitor_8000 | 朝阳 | VN28000 | 73.08 | 东
2025-01-01 00:16:39+00:00 | DEV_6000 | monitor_6000 | 朝阳 | VN46000 | 78.77 | 东
2025-01-01 00:16:39+00:00 | DEV_10000 | monitor_10000 | 朝阳 | VN30000 | 71.95 | 东
2025-01-01 00:16:39+00:00 | DEV_4000 | monitor_4000 | 朝阳 | VN4000 | 79.80 | 东
2025-01-01 00:16:39+00:00 | DEV_2000 | monitor_2000 | 朝阳 | VN62000 | 79.74 | 东

可以看到，查询成功返回了朝阳区的超速记录，最高时速达 79.80 km/h。

通过这次裸测，可以清晰地看到 kwdb-text2sql-aiot 在没有数据治理的情况下，实际依赖以下三个机制：

**① information_schema（标准 SQL 元信息，任何数据库自带，无需额外配置）**

`information_schema.columns` 提供了完整的表结构和字段类型信息，这是所有关系型数据库的 ANSI SQL 标准接口，任何前端工具都可以直接查询，不需要额外的元数据管理平台。

② 列名语义映射能力

kwdb-text2sql-aiot 内置的列名语义字典能够将 `district`、`speed`、`pass_time`、`device_code` 与"区""速度""时间""卡口编号"等业务概念对应起来。这种映射能力来自内置规则。

**③ 外键关系识别**

`traffic_flow.device_code` 和 `monitor_location.device_code` 之间虽然没有显式的外键约束（`information_schema.table_constraints` 中查不到相关记录），但 kwdb-text2sql-aiot 内置的列名一致性规则可以识别出这是一个潜在 JOIN 条件。同理，`traffic_flow.plate_no` 和 `vehicle_info.plate_no` 的列名一致性也会被识别为 JOIN 条件。

**它做不到的三件事**

| 场景 | 表现 | 根本原因 |

|------|------|----------|

| **同名异义字段** | `name` 列在 traffic_flow 和 monitor_location 里各指什么？kwdb-text2sql-aiot 只能根据上下文猜测 | 无列注释，无业务字典 |

| **无显式关联** | 两张表没有外键约束、也没有相同列名时，kwdb-text2sql-aiot 可能 JOIN 错表或根本不知道要 JOIN | 缺少关系元信息 |

| **业务口径缺失** | "超速"是 >60 还是 >80？"近一小时"从哪个时间点算起？ | 无业务规则层，纯语法转换 |

这一测试印证了一个朴素的结论：**kwdb-text2sql-aiot 能用，但数据治理决定上限**。元信息越完整——列有注释、表有业务描述、外键关系清晰——kwdb-text2sql-aiot 的准确率越高；没有这些，它靠列名和规则模板猜，能跑通但结果不可完全信赖。生产环境中，建议在 Schema 层面补全列注释（哪怕是简短的中文说明），这是投入产出比最高的数据治理动作。

图 4-1（续） kwdb-text2sql-aiot 能力边界示意图 ┌──────────────────────────────────────────────────────────┐ │ 依赖项对 text2sql 准确率的影响 │ ├────────────────────┬───────────────────┬──────────────────┤ │ 元信息类型 │ 有无 │ 准确率表现 │ ├────────────────────┼───────────────────┼──────────────────┤ │ information_schema │ 有（标准SQL自带） │ ✅ 表结构自动获取 │ │ 外键约束 │ 有 │ ✅ JOIN 关系确定 │ │ 列注释 │ 有 │ ✅ 语义零误判 │ │ 外键约束 │ 无 │ ⚠️ 靠列名推断 │ │ 列注释 │ 无 │ ⚠️ 靠模型猜，可能错│ │ 业务字典 │ 无 │ ❌ 口径无法判断 │ └────────────────────┴───────────────────┴──────────────────┘

---

五、运维巡检与性能：kwdb-intelligent-inspection + kwdb-performance-review

5.1 kwdb-intelligent-inspection：runbook 化的集群健康检查

kwdb-intelligent-inspection 的激活方式：在 Skill 触发器中注册了关键字（如"巡检""健康检查""集群状态""kwdb-intelligent-inspection"）。用户输入"帮我巡检一下 KWDB 集群"，Skill 识别后自动进入四步闭环：① 采集节点状态（CPU/内存/磁盘）；② 与预置规则比对；③ 生成带来源标注的巡检报告；④ 返回异常项和处置建议。用户看到的不再是原始的 system_finished_history 输出，而是一份可直接执行的巡检结论。这些 Skill 的共同点是：本质上是"带判断条件的工作流"，不是简单的脚本。WorkBuddy 通过关键字匹配识别用户意图，自动路由到对应 Skill，Skill 再按预置逻辑执行。整个链路是：自然语言 → 意图识别 → Skill 触发 → 结构化输出。

**场景**：每日上午 9 点需向指挥中心汇报系统状态，包括数据库可用性、存储空间、QPS 和慢查询情况。

kwdb-intelligent-inspection Skill 将巡检任务固化为"确认目标 → 采集指标 → 应用规则 → 生成报告"四步。关键原则是：默认规则与用户自定义阈值分开处理，避免规则覆盖导致的误报。

**采集指标示例**：

-- 1. 数据库可用性
SHOW DATABASES;

-- 2. 表统计
SELECT
table_name,
(data_size / 1024 / 1024) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'defaultdb';

**SHOW JOBS 新特性（3.1.0 新增）**：

3.1.0 中 SHOW JOBS 命令支持显示流计算、数据订阅和发布的相关信息。实测可见系统后台每小时自动执行 SYNC META CACHE 任务：

图 5-1 kwdb-intelligent-inspection 四步流程

┌────────────────────┐
│ ① 确认目标与范围 │ 哪些集群/哪些库表/哪些指标
└────────────────────┘
│
▼
┌────────────────────┐
│ ② 采集指标 │ CPU/内存/磁盘/QPS/慢查询
└────────────────────┘
│
▼
┌────────────────────┐
│ ③ 应用规则 │ 默认规则 + 用户自定义阈值
└────────────────────┘
│
▼
┌────────────────────┐
│ ④ 生成报告 │ 结论+建议+数据来源标注
└────────────────────┘

5.2 kwdb-performance-review：慢 SQL 四步闭环

**场景**：指挥中心反映某张报表查询越来越慢，需要定位原因。

kwdb-performance-review Skill 按"解析执行计划 → 识别反模式 → 改写 SQL → 验证结果"四步推进。

**常见时序场景反模式识别**：

| 反模式 | 说明 | 正确做法 |

|--------|------|----------|

| SELECT * | 时序场景全字段扫描 | 只取所需字段 |

| 无主标签过滤 | 触发全表时序扫描 | 必须带 device_code 条件 |

| 深度分页 | 时序数据 OFFSET 大时性能差 | 用 WHERE pass_time > X 代替 |

| 跨模 JOIN 无索引 | traffic_flow.device_code 无显式外键索引 | 确认索引存在 |

**kwdb-performance-review 的关键区分**：

Skill 会首先区分关系表和时序表的索引场景——将关系型数据库的二级索引经验直接迁移到时序场景是常见误区。例如，时序表的 Primary Tag 本身就是最优先的过滤条件，不需要额外创建普通索引。

**VACUUM TS DATABASES（3.1.0 新增）**：

3.1.0 支持手动触发时序数据重组，立即释放存储空间：

VACUUM TS DATABASES;

VACUUM

执行成功，存储空间重组立即生效。相比等待系统自动触发，运维人员可以主动控制重组时机（例如夜间低峰期）。

---

六、故障诊断：kwdb-troubleshooting

**场景**：某日凌晨接到报警，某卡口数据写入延迟。

kwdb-troubleshooting Skill 将故障分为功能、性能、混合和集群可用性四类，从时间和证据出发收敛排查范围。

**排查路径**：

图 6-1 kwdb-troubleshooting 证据收敛流程

"某卡口数据延迟" ──▶ 事件分类（功能/性能/混合/可用性）
│
▼
时间窗口收敛
(告警时间 → ±30min)
│
▼
┌─────────────────────┐
│ 定位首条决定性证据 │
│ (日志/指标/慢查询) │
└─────────────────────┘
│
▼
┌─────────────────────┐
│ 确定性结论 vs 猜测 │
│ 材料不足写"待补充" │
└─────────────────────┘

**KWDB 3.1.0 运维增强**：

3.1.0 在故障诊断相关能力上有以下增强：

- **Raft Log 专用存储引擎**：新增机械硬盘读写优化，当副本间同步延迟时，Raft 日志写入性能提升有助于加快数据一致性恢复。

- **ts.last_cache_size.max_limit**：3.1.0 新增 last_row() 读缓存内存限制参数，提升最新值查询响应速度——last_row() 查询慢是时序数据库常见故障之一。

- **连接能力提升**：最大并发连接数提升至 50,000，避免高并发写入场景下的连接耗尽问题。

---

七、KWDB 3.1.0 新特性实测

7.1 IF NOT EXISTS 建表

前文已验证，`CREATE TABLE IF NOT EXISTS` 语法可用，避免脚本重复执行报错。

7.2 to_timestamp() 新函数

3.1.0 新增 `to_timestamp()` 函数，支持时间戳（Unix Epoch）到时间格式的转换。实测：

SELECT to_timestamp(1704067200) AS ts_convert;

ts_convert
-----------------------------
2024-01-01 00:00:00+00:00

1704067200 对应 2024 年 1 月 1 日零点的 Unix 时间戳，转换正确。在卡口数据处理中，常需要将第三方系统传来的 Unix 时间戳转为数据库可读的 TIMESTAMP，3.1.0 之前需要依赖 `CAST(epoch AS TIMESTAMP)` 语法，现在有了更直观的函数。

7.3 SHOW JOBS 全链路任务信息

如前所示，SHOW JOBS 在 3.1.0 中返回了更完整的任务信息，包括 SYNC META CACHE（每小时自动执行）、TS TXN 事务处理等任务类型，运维人员无需再通过多个系统命令拼凑任务状态。

7.4 VACUUM TS DATABASES 手动重组

前文已实测，执行后立即触发时序表的存储重组，相比系统后台自动触发更可控。

7.5 last_row() 读缓存优化

3.1.0 通过 `ts.last_cache_size.max_limit` 参数控制 last_row() 读缓存的内存上限，避免缓存过大导致 OOM。实测 DEV_1 设备的最新记录查询：

SELECT device_code, speed, direction, pass_time
FROM traffic_flow
WHERE device_code = 'DEV_1'
ORDER BY pass_time DESC
LIMIT 1;

device_code | speed | direction | pass_time
-------------+-------+-----------+---------------------------
DEV_1 | 74.70 | 东 | 2025-01-01 00:16:39+00:00

在 3.1.0 之前，这类"取某设备最新一条记录"的查询在高并发场景下容易成为瓶颈；新版本通过缓存机制优化后，响应速度预计有显著提升。

图 7-1 KWDB 3.1.0 核心新特性总览

┌─────────────────────────────────────────────────────────────┐
│ KWDB 3.1.0 核心新特性 │
├─────────────────┬───────────────────────────────────────────┤
│ 数据库对象管理 │ IF NOT EXISTS 建表 │
│ │ 存储过程支持自定义变量 │
│ │ PREPARE/EXECUTE/DEALLOCATE │
├─────────────────┼───────────────────────────────────────────┤
│ 数据写入与处理 │ 数据去重策略 merge 模式 │
│ │ Raft Log 专用存储引擎（机械硬盘优化） │
│ │ 最新数据段压缩控制（ts.compress.last_*） │
├─────────────────┼───────────────────────────────────────────┤
│ 查询与分析 │ last_row() 读缓存内存限制（ts.last_*） │
│ │ 最大并发连接数提升至 50,000 │
│ │ to_timestamp() 时间戳转换函数 │
├─────────────────┼───────────────────────────────────────────┤
│ 运维与管理 │ 多副本集群扩缩容脚本 │
│ │ VACUUM TS DATABASES 手动触发重组 │
│ │ SHOW JOBS 全链路任务信息 │
│ │ 便捷运维脚本 kw-status.sh / kw-sql.sh │
└─────────────────┴───────────────────────────────────────────┘

---

八、Skill 组合案例：一次完整的 KWDB 多模数据分析闭环

KWDB 官方工具箱共 9 个 Skill，扣除部署（kwdb-install-deploy）与源码构建（kwdb-build）后，面向业务的是 7 个 Skill。本文围绕交通卡口场景，实际串联实测其中 6 个（时序异常检测 kwdb-ts-anomaly-detection 的检测场景与本文交通数据不契合，未单独展开）：

图 8-1 Skill 工具箱全流程覆盖 ┌──────────────────────────────┐ │ kwdb-schema-design │ 新卡口接入 → 生成 DDL → SHOW CREATE TABLE 验证 └────────────┬─────────────────┘ │ ▼ ┌──────────────────────────────┐ │ kwdb-data-migration │ 历史 Oracle 数据迁移 → 兼容性校验 → 确认门 └────────────┬─────────────────┘ │ ▼ ┌──────────────────────────────┐ │ kwdb-text2sql-aiot │ "朝阳区近1小时超速" → 自然语言 → 可验证 SQL └────────────┬─────────────────┘ │ ▼ ┌──────────────────────────────┐ │ kwdb-intelligent-inspection │ 集群健康检查 → VACUUM TS → SHOW JOBS 巡检 └────────────┬─────────────────┘ │ ▼ ┌──────────────────────────────┐ │ kwdb-performance-review │ 执行计划解析 → 反模式识别 → SQL 改写 → 验证 └────────────┬─────────────────┘ │ ▼ ┌──────────────────────────────┐ │ kwdb-troubleshooting │ 证据收敛 → 故障分类 → 确定性结论 └──────────────────────────────┘

在这个流程中，Skill 之间存在数据衔接：kwdb-schema-design 生成的表结构作为 kwdb-data-migration 的迁移目标；kwdb-text2sql-aiot 生成的 SQL 输出可以作为进一步数据分析的数据源；kwdb-performance-review 的慢 SQL 改写结果需要 kwdb-intelligent-inspection 确认是否涉及系统级参数修改。

---

九、征文总结

**KWDB 3.1.0 的核心价值**：

从本文的实测来看，3.1.0 的增量更新集中在"让已有的能力更好用"：IF NOT EXISTS 减少运维摩擦、to_timestamp() 简化数据转换、VACUUM TS 给予运维人员主动权、last_row() 缓存突破高频查询瓶颈。这些改进看似不大，但每一个都对应着生产环境中的高频痛点。

**Agent Skill 工具箱的核心价值**：

本文实测的 6 个 Skill 各自解决一类具体问题：kwdb-schema-design 解决"DDL 凭经验拍脑袋"——先确认负载类型再生成可验证 DDL；kwdb-data-migration 解决"迁移不可逆"——用确认门把每个高风险步骤显式暴露给操作者；kwdb-text2sql-aiot 解决"自然语言查询不可信"——附带假设清单，让生成的 SQL 可验证、可追溯；kwdb-intelligent-inspection 解决"巡检靠人肉"——把 runbook 固化为四步闭环并标注指标来源；kwdb-performance-review 解决"慢 SQL 改写后不知道是否生效"——执行计划前后对比让效果一目了然；kwdb-troubleshooting 解决"故障排查靠猜"——按时间和证据收敛范围，给出确定性结论。它们的共同点不是"更会聊天"，而是把 DBA 的经验拆成可复用、可审计的操作协议。

**对 KWDB 社区的期待**：

建议社区后续在以下方向继续发力：时序表与向量检索的融合（例如与 Milvus 的对接）、Kubernetes 原生 Operator 的完善、以及 SampleDB 示例库的持续扩充（当前示例偏基础，高级场景较少）。

开源社区的繁荣，靠的不只是核心代码的贡献者，也靠每一个愿意把踩坑经验写出来的使用者。感谢 KWDB 社区提供了这么完整的 Skill 工具链，让 DBA 从"救火队员"逐步变成"流程设计者"。

---

*本文全部 SQL 均在 KWDB 3.1.0（容器镜像：registry.cn-hangzhou.aliyuncs.com/kwdb/kwdb:3.1.0）上逐条实测通过。实测环境：10.60.143.102，数据集：1 万卡口 + 10 万车辆 + 100 万过车记录。* 本文最后更新：2026年10月25日 13:20