企业官网建设流程全解析

StarRocks 数据写入实操：一条 INSERT 从建表、小批写入到按天回刷的完整闭环

【免费下载链接】starrocksThe world's fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks

你要把一批数据写进 StarRocks——几十行测试数据、一天的设备监控日志，或者一张按天聚合好的结果表，INSERT 语句通常是最先想到的入口。下面这条动手路径覆盖建分区表、小批量插入验证、INSERT INTO SELECT 批量插入，直到指定分区的回刷覆盖，全部用一套统一的 IoT 监控业务数据演示。

先判断：这份数据该不该用 INSERT 写

这一节帮你花 30 秒判断手里的数据适不适合走 INSERT，避免把大批量、高频的活儿压在同步语句上。

StarRocks 里 FE 是负责元数据和 SQL 解析的前端节点，BE 是真正存数据、跑计算的存储计算节点；一次 INSERT 由 FE 拆成计划，交给各 BE 并行执行后再汇总。判断标准很简单：

• 数据量：单次几千到几十万行，INSERT INTO SELECT 很轻松；VALUES 直插只适合百行以内的验证和小修补。
• 写入频次：一天跑几次的离线 ETL 没问题；每秒多条的流式数据不适合反复发 INSERT，频繁的短小导入会不断产生数据版本，拖慢查询。这类场景交给 Routine Load（Kafka 持续导入）或 Flink Connector 更合适。
• 实时性要求：INSERT 是同步作业，执行完才可见，做小时级、天级报表完全够用；要秒级可见就上 Stream Load。
• 数据来源：源数据已经在 StarRocks 里（内部表、外部表、HDFS/云存储文件），INSERT 一条语句就能搬；源数据散落在业务库持续产生，那是 Broker Load、Routine Load 的地盘，本文不展开。

一句话：批量、定时、源数据可查询——满足这三条，INSERT 就是正解。

第一条能跑的 INSERT：建表 → 插入 → 验证

这一节给你一个可复制的最小闭环，把列名指定、全列插入这些语法点直接嵌在代码里讲。

先建一张按天分区的监控明细表。分区把表按时间切成一段段独立数据，查询某一天的数据时只扫对应分区，写入时也能按分区路由：

CREATE DATABASE IF NOT EXISTS iot_monitor; CREATE TABLE iot_monitor.device_metric ( ts DATETIME NOT NULL, device_id VARCHAR(32) NOT NULL, region VARCHAR(16), metric_name VARCHAR(32), metric_value DOUBLE, quality TINYINT ) DUPLICATE KEY(ts, device_id, region) PARTITION BY RANGE(ts) ( PARTITION p20260910 VALUES [('2026-09-10 00:00:00'), ('2026-09-11 00:00:00')), PARTITION p20260911 VALUES [('2026-09-11 00:00:00'), ('2026-09-12 00:00:00')) ) DISTRIBUTED BY HASH(device_id);

DUPLICATE KEY 模型表示同一行可以重复插入（明细日志就是这种语义），分桶键 device_id 决定数据在 BE 之间怎么散列。

再插入三条小批量数据做验证。注意这里用的是显式列名写法，列和值按名字对应，不依赖建表时的列顺序，改表结构后也不容易错位：

INSERT INTO iot_monitor.device_metric (ts, device_id, region, metric_name, metric_value, quality) VALUES ('2026-09-11 08:00:00', 'dev-001', 'cn-east', 'cpu', 72.5, 1), ('2026-09-11 08:00:00', 'dev-002', 'cn-north', 'temp', 61.3, 1), ('2026-09-11 08:05:00', 'dev-001', 'cn-east', 'temp', 88.9, 1);

不写列名的全列插入也合法，但 VALUES 里必须按建表顺序补齐全部 6 列，漏一列、错一位都会写进错误的列——生产里建议始终显式列名。

插入完成后做两件事验证闭环：

SELECT device_id, region, metric_name, metric_value FROM iot_monitor.device_metric ORDER BY ts LIMIT 10; SHOW PARTITIONS FROM iot_monitor.device_metric;

第一条查询确认数据内容，SHOW PARTITIONS看 p20260911 的行数是不是 3，顺便确认数据落进了正确的分区。

业务里最常见的三种 INSERT INTO SELECT 写法

三种写法分别对应报警明细、按天汇总、历史回刷，每条后面都附一个容易踩的坑。

只写异常行：条件过滤写入

监控明细里 value 超过阈值的行需要进报警表。目标表先建好（单分区、不分桶到很细），然后一条 INSERT INTO SELECT 完成筛选加落表：

CREATE TABLE iot_monitor.device_alarm ( ts DATETIME NOT NULL, device_id VARCHAR(32) NOT NULL, region VARCHAR(16), metric_name VARCHAR(32), metric_value DOUBLE, alarm_level TINYINT ) DUPLICATE KEY(ts, device_id) DISTRIBUTED BY HASH(device_id); INSERT INTO iot_monitor.device_alarm SELECT ts, device_id, region, metric_name, metric_value, IF(metric_value > 85, 1, 0) AS alarm_level FROM iot_monitor.device_metric WHERE ts >= '2026-09-11 00:00:00' AND metric_value > 80;

坑提醒：WHERE 里带上ts条件不只是过滤，更是让源表走分区裁剪，否则每次全表扫。

按天写汇总表：先聚合再插入

报表要的是"每台设备每天平均 CPU、最高温度"，而不是明细。聚合放在 SELECT 里完成，写入目标就是聚合结果：

CREATE TABLE iot_monitor.device_daily_agg ( dt DATE NOT NULL, device_id VARCHAR(32) NOT NULL, region VARCHAR(16), avg_cpu DOUBLE, max_temp DOUBLE, report_cnt BIGINT ) DUPLICATE KEY(dt, device_id, region) PARTITION BY RANGE(dt) ( PARTITION p20260911 VALUES [('2026-09-11'), ('2026-09-12')) ) DISTRIBUTED BY HASH(device_id); INSERT INTO iot_monitor.device_daily_agg SELECT DATE(ts) AS dt, device_id, region, AVG(IF(metric_name = 'cpu', metric_value, NULL)) AS avg_cpu, MAX(IF(metric_name = 'temp', metric_value, NULL)) AS max_temp, COUNT(*) AS report_cnt FROM iot_monitor.device_metric WHERE ts >= '2026-09-11 00:00:00' AND ts < '2026-09-12 00:00:00' GROUP BY DATE(ts), device_id, region;

坑提醒：GROUP BY的粒度必须覆盖目标表的 KEY 列（dt、device_id、region），聚合后出现完全重复的行会让下游报表翻倍。

按天分区回刷：指定分区 + OVERWRITE 覆盖

某天上游数据错了，重跑这一天时不能追加（会重复），要用 INSERT OVERWRITE 整体替换分区。这是 INSERT 最容易被低估的能力——v2.4 起支持，整个过程是"写临时分区再原子替换"，中间态不会被查询看到：

INSERT OVERWRITE iot_monitor.device_metric PARTITION(p20260911) SELECT ts, device_id, region, metric_name, metric_value, quality FROM iot_monitor.device_metric WHERE ts >= '2026-09-11 00:00:00' AND ts < '2026-09-12 00:00:00' AND quality = 1;

坑提醒：PARTITION(p20260911)指定的分区必须已存在，回刷的日期范围必须和分区边界严格对齐，只覆盖分区里被 SELECT 命中的数据范围之外的行会直接消失。另外建表时若开启自动分区（PROPERTIES 里配置auto_partition相关属性），新的一天首次写入会按需建好分区，不用手工补 DDL。

写得快写得稳：性能与并发的几条硬规则

这一节把调优经验浓缩成一张对照清单，照着检查即可，不用背参数。

补充两条习惯：大批量搬运优先用 INSERT INTO SELECT 而不是拼超长 VALUES（前者多 BE 并行，后者受单条 SQL 尺寸限制）；同一张表上并发写和重查询打架时，用资源组把导入流量隔离出去。

写错了先看这里

四个高频问题按"报错 → 原因 → 处理"过一遍，基本覆盖九成线上情况。

报错Partition not found或Partition does not exist原因：分区表的写入时间落在没建过的分区里，或者 OVERWRITE 指定的分区名拼错。 处理：先SHOW PARTITIONS FROM 表名核对；长期方案是开启自动分区，让新日期的写入自动建分区。

报错Memory of ... exceed limit原因：单条 INSERT INTO SELECT 的中间结果（大 JOIN、大 GROUP BY）在 BE 上超内存。 处理：缩小单次写入的时间范围，按天拆成多个作业跑；确实需要一次性处理时，临时调大 BE 内存上限并观察是否伴随磁盘溢出。

报错Data length too long或严格模式整批失败原因：默认严格模式下，一行字符串超长、类型转换失败，整条 INSERT 就中止。 处理：想容忍脏数据就SET enable_insert_strict = false;让不合格行被过滤后继续；但过滤后务必比对源和目标行数，别把静默丢数当成正常。

NULL 写不进去，报列相关错误原因：目标列声明了 NOT NULL 且没有 DEFAULT，SELECT 结果里却是 NULL。 处理：要么建表时给列NOT NULL DEFAULT '未知'，要么写入时用COALESCE(metric_name, 'unknown')兜底。NULL 本身 StarRocks 完全支持，问题只在"没有默认值的非空列"上。

一条记忆点：INSERT 适合"批量、定时、可查询的源"，小批量验证用 VALUES、搬数用 INSERT INTO SELECT、重跑用 OVERWRITE 指定分区——三种姿势对上三种场景就够了。想深入语法细节，看仓库里的 INSERT 语句导入数据完整文档，流式场景对照 Stream Load 数据加载文档。

【免费下载链接】starrocksThe world's fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks