InfluxDB作为一款面向时间序列数据的数据库，在监控、物联网等场景下被广泛使用。时序数据的特点是写入量大、时间跨度长，如果所有数据都以原始精度保存，磁盘占用会很快失控。降采样就是解决这个问题的常见手段：把高频原始数据聚合成低频数据写入新的measurement，配合保留策略（Retention Policy）让原始数据过期删除，只保留聚合结果。而实现降采样写入的核心语句，就是SELECT INTO。这篇文章详细拆解它的用法和容易踩的坑。
SELECT INTO的基本语法与工作原理
SELECT INTO的作用是在查询的同时，把查询结果写入到指定的measurement中。它本质上是一条"查询加写入"的复合语句，InfluxDB会在服务端完成整个流程，不需要客户端来回搬运数据。基本语法如下：
SELECT <field> INTO <target_measurement> FROM <source_measurement> WHERE <time条件> GROUP BY time(<interval>)
举个具体例子，假设有一个measurement叫cpu_usage，每10秒写入一次，现在想把它聚合成每5分钟一个点的数据，写入cpu_usage_5m：
SELECT mean("value") INTO "cpu_usage_5m" FROM "cpu_usage"
WHERE time >= '2024-01-01T00:00:00Z' AND time < '2024-01-02T00:00:00Z'
GROUP BY time(5m)
执行后，InfluxDB会按5分钟的时间窗口对value字段求平均，并把结果作为新的point写入cpu_usage_5m。目标measurement会自动继承聚合后的时间戳，每个窗口的时间戳默认是窗口的起始时刻。
有几个细节需要注意。第一，SELECT INTO只针对field做聚合，tag默认会保留，除非你在语句里明确指定tag的处理方式。第二，如果查询里使用了GROUP BY time()，必须配合WHERE子句限定时间范围，否则会报错。第三，写入的目标measurement如果已存在同名series，新数据会按时间戳覆盖旧数据，这一点在做数据回填时要格外小心。
配合保留策略设计降采样链路
单独一条SELECT INTO只是手动执行一次聚合，真正的降采样体系需要保留策略（Retention Policy）参与。典型的做法是三层数据结构：原始数据放在短周期的RP里，比如7天自动删除；降采样数据放在长周期RP里，保存一年甚至永久。先创建两个RP：
CREATE RETENTION POLICY "rp_raw" ON "monitor_db" DURATION 7d REPLICATION 1 DEFAULT; CREATE RETENTION POLICY "rp_downsampled" ON "monitor_db" DURATION 365d REPLICATION 1;
然后在SELECT INTO里指定目标RP和measurement，完整写法是在INTO后面带上RP限定：
SELECT mean("value") INTO "rp_downsampled"."cpu_usage_5m" FROM "rp_raw"."cpu_usage"
WHERE time >= now() - 1h
GROUP BY time(5m)
这样原始数据7天后自动清理，聚合数据则保存一年。需要注意的是，如果查询语句里没有写RP，默认查询的是数据库的DEFAULT RP，跨RP操作时一定要显式写全，否则容易出现查不到数据或者写错位置的诡异问题。
另一个常见需求是多个聚合函数同时降采样，比如均值、最大值、最小值都要保留。SELECT INTO支持多字段写入，写法如下：
SELECT mean("value") AS "value_avg", max("value") AS "value_max", min("value") AS "value_min"
INTO "rp_downsampled"."cpu_usage_5m" FROM "rp_raw"."cpu_usage"
WHERE time >= now() - 1h
GROUP BY time(5m)
通过AS别名，三条聚合结果会作为三个不同的field写入目标measurement，查询时可以一次性取回，结构上非常清爽。
用连续查询实现自动降采样
手动执行SELECT INTO适合一次性任务或者数据回填，线上持续运行的降采样一般用连续查询（Continuous Query，简称CQ）。CQ会按照设定的周期自动在数据库内部执行SELECT INTO，无需外部调度。创建语句示例：
CREATE CONTINUOUS QUERY "cq_cpu_5m" ON "monitor_db"
RESAMPLE EVERY 5m FOR 10m
BEGIN
SELECT mean("value") INTO "rp_downsampled"."cpu_usage_5m" FROM "rp_raw"."cpu_usage"
GROUP BY time(5m), *
END
这段语句的含义是：每5分钟执行一次查询，每次覆盖最近10分钟的数据窗口。RESAMPLE子句是调优的关键。EVERY控制执行频率，FOR控制每次回看的窗口长度。如果不写FOR，CQ只会覆盖与执行间隔相同长度的窗口，一旦有数据延迟写入，就会漏掉聚合。把FOR设成间隔的两倍，可以容忍一定程度的数据迟到，这是一个比较稳妥的实践。
GROUP BY末尾的星号表示保留所有tag，让降采样数据继承原始数据的tag维度，这样按主机、按机房等维度的下钻查询在聚合数据上依然可用。漏写星号是新手最常犯的错误之一，后果是聚合数据丢失了所有维度信息，只能看到全局汇总，后期想补都补不回来。
CQ的执行状态可以通过SHOW CONTINUOUS QUERIES查看，降采样是否正常产出数据，可以用简单的SELECT验证：
SELECT * FROM "rp_downsampled"."cpu_usage_5m" WHERE time >= now() - 1h LIMIT 10
常见问题与注意事项
首先是时间窗口对齐问题。GROUP BY time(5m)默认按整点对齐，即00:00、00:05这样的边界。如果你的数据写入时间不是从整点开始，可能希望窗口按数据实际起点对齐，这时需要用到offset参数，例如GROUP BY time(5m, 2m)表示窗口整体偏移2分钟。合理使用offset可以让窗口边界与业务节奏吻合，减少窗口边界处的数据抖动。
其次是空窗口的处理。某个时间窗口内如果完全没有原始数据，SELECT INTO不会为这个窗口生成任何point，聚合数据会出现时间上的空洞。下游如果对时间连续性有要求，需要自己做插值或者在展示层处理断点，InfluxDB本身不会自动补零。
第三是性能开销。SELECT INTO本质上是一次全量扫描加写入，如果原始measurement的cardinality很高（tag组合数多），聚合过程会消耗不少CPU和内存。降采样任务尽量避开写入高峰期，大范围的历史数据回填建议分批次执行，每次限定一个较短的时间区间，避免单次语句扫描时间过长导致超时。
最后提醒一点，InfluxDB 2.x之后官方推荐用Task配合Flux语言来做降采样，SELECT INTO和CQ主要用于1.x版本。如果你的系统还在1.x，或者使用的是兼容1.x接口的衍生版本，本文的方案依然是标准做法。升级到2.x的项目，可以参考Flux的aggregateWindow函数实现同样的效果，思路是一致的，只是语法换了。
总结一下，SELECT INTO配合保留策略和连续查询，构成了一套完整的时序数据降采样方案。核心要点包括：明确目标RP、GROUP BY time()配合时间过滤、CQ的RESAMPLE调优、以及用星号保留tag维度。把这些细节处理到位，就能用较低的存储成本支撑长时间跨度的历史数据查询。
InfluxDBSELECT INTO降采样修改时间：2026-09-13 08:50:31