StarRocks 数据写入轻松上手用 INSERT 语句跑通 5 个真实导入场景【免费下载链接】starrocksThe worlds 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凌晨两点被叫起上个月漏了一笔订单要连夜补进仓里。数据不大几十 MB逐条粘贴太慢——这种“量不算大、但要马上能查”的活儿用 StarRocks INSERT 语句往往最省事。下面按“先选工具、再动手、套场景、避坑、收尾”的顺序像旁边坐个老同事给你演示一样15 分钟过一遍。先选对再动手INSERT 和 Stream Load 怎么选动手前花 30 秒判断“我这种情况该不该用 INSERT”。四种常用写入方式的适用边界导入方式数据量级时效要求数据来源INSERT 语句小KB百 MB即席写完就查VALUES / 内表外表 / FILES()Stream Load中MBGB近实时、按批推HTTP 推流、本地文件Broker Load大GBTB准实时、离线批HDFS / 对象存储Routine Load持续小批分钟级流式Kafka 等消息队列一句话数据不大、来源是 SQL 能查到的表或文件、要求“现在就要”——选 INSERT。量到 GB 级以上或要长期流式灌数就别用它了。官方文档INSERT 语句导入数据。写进第一条数据建表到验证三步走先用一张最小的订单表把链路跑通。建表一个最简的订单明细表CREATE TABLE orders_2024 ( order_time DATETIME, product VARCHAR(50), amount DECIMAL(10,2), quantity INT ) DUPLICATE KEY(order_time, product) DISTRIBUTED BY HASH(product);写入第一批数据这里只插 3 行做验证-- 插入 3 条订单明细做验证 INSERT INTO orders_2024 (order_time, product, amount, quantity) VALUES (2024-01-12 10:00:00, Laptop, 1599.99, 3), (2024-01-12 11:30:00, Dress, 159.99, 8), (2024-01-13 09:00:00, Monitor, 299.99, 5);查询验证确认数据真的落进去了-- 核对刚写入的 3 条 SELECT order_time, product, amount FROM orders_2024 ORDER BY order_time;链路通了后面都在这条主线上加料。INSERT INTO VALUES适合少量验证数据真到几十 MB 以上官方文档更建议换 Stream Load 或 Broker Load见导入数据概述。按场景套用的写法把大额订单单独捞出来入仓场景风控想单独盯着超过 1000 块的大单。用INSERT INTO SELECT加个WHERE就能捞。-- 只把满足条件的大额订单抽到 high_value 表 INSERT INTO high_value_orders SELECT order_time, product, amount FROM orders_2024 WHERE amount 1000 AND quantity 3;目标表列要能和SELECT出来的列对得上顺序或列名不一致会报解析错。默认严格模式下只要有一条数据不合目标表格式如字符串超长整条就失败需要容错时可把会话变量enable_insert_strict设为false具体版本以官方文档为准。多张表汇总成一张报表场景财务要一张“类目 × 销售额”的日报订单表和商品维表都得用。-- 订单关联商品维表按类目汇总 INSERT INTO sales_daily SELECT p.category, SUM(o.amount) AS total, COUNT(*) AS cnt FROM orders_2024 o JOIN products p ON o.product p.product GROUP BY p.category;源表可以是多张内表/外表但目标表必须是 StarRocks 内表。GROUP BY聚合在写入端完成等于把一次 ETL 折进了一条 SQL。按天分区补历史数据场景分区表要补 1 月数据别动 2 月以后的分区。-- 指定分区写入其余分区不受影响 INSERT INTO orders_2024 PARTITION(p01, p02) SELECT * FROM staging.orders_raw WHERE order_time 2024-01-01 AND order_time 2024-02-01;同一天算错了想重跑用INSERT OVERWRITE做原子覆盖——先写临时分区再替换不会留下脏数据-- 重跑 1 月分区临时分区原子替换 INSERT OVERWRITE orders_2024 PARTITION(p01) SELECT * FROM staging.orders_raw WHERE order_time 2024-01-01 AND order_time 2024-01-02;分区名必须是目标表已存在的分区写不存在的名会报错。INSERT OVERWRITE全程在 Leader FE 执行过程中 Leader 宕机会导致这次覆盖失败。踩坑清单报错现象 → 一行原因 → 解决动作 提示语法解析错误 / 类型转换失败源列类型和目标列对不上、或目标列没默认值 → 对齐列名与顺序或补齐DEFAULT。字符串超长 / 格式不合导致整批失败默认严格模式不容错 → 确认是否真需容错必要时设enable_insert_strictfalse。写完不知道成没成功网络抖动丢了返回结果 → 给作业加WITH LABEL之后SHOW LOAD WHERE label...回查-- 用 label 回查这次导入结果 SHOW LOAD WHERE label insert_load_202401;频繁小批量 INSERT 后查询变慢版本碎片多 → 别把 INSERT 当日常例行导入改用 Routine Load 等流式方案。补分区报分区不存在PARTITION(...)里的分区没建 → 先建分区或改用列表达式分区让其自动创建。更多排障可查数据加载目录。收尾效率清单让 INSERT 跑得快批量写别逐条提交只插需要的列写入前做好清洗过滤并发别太高几路就够给作业加 Label 便于回查最后提醒一句什么时候不该用 INSERT——数据量到 GB 级以上、或要长期分钟级流式灌数就别拿 INSERT 硬扛交给 Stream Load / Broker Load / Routine LoadINSERT 的定位是即席、中小批量、写完即查。性能提升幅度因集群与数据而异以实测为准。【免费下载链接】starrocksThe worlds 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考