InfluxDB 1.x 支持 SQL 风格 DELETE 语句（如 DELETE FROM "cpu" WHERE time < '2024-01-01T00:00:00Z'），而 2.x 不支持该语法，须调用 /api/v2/delete 接口并提供 org、bucket、start/stop 及 token。
用 DELETE 语句删数据，但得先确认 InfluxDB 版本
InfluxDB 1.x 和 2.x 的删除方式完全不同，不看版本直接写 DELETE 很可能报错或没效果。1.x 支持 SQL 风格的 DELETE，而 2.x（含 Cloud）默认禁用该操作，必须通过 API 或 influx delete 命令执行。
Go 程序里调用时，本质是发 HTTP 请求——所以关键不是“Go 怎么写”，而是“该往哪个 endpoint 发什么 payload”。
- 查版本：请求
http://localhost:8086/ping，看响应头X-Influxdb-Version - InfluxDB 1.x：走
/query接口，q=DELETE FROM "measurement" WHERE time < '2024-01-01' - InfluxDB 2.x：走
/api/v2/delete，需提供org、bucket、start/stop时间范围，且必须带有效 token
InfluxDB 1.x：Go 中用 http.PostForm 发 DELETE
1.x 的 DELETE 是同步阻塞操作，会锁住 shard 一段时间，大范围删除容易超时或夯住写入。
示例代码片段（注意 URL 编码和错误检查）：
立即学习“go语言免费学习笔记（深入）”；
resp, err := http.PostForm("http://localhost:8086/query",
url.Values{
"q": {"DELETE FROM \"cpu\" WHERE time < '2024-01-01T00:00:00Z'"},
"db": {"telegraf"},
"rp": {""}, // 可选 retention policy
})
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close()
// 检查 resp.StatusCode == 200，且 resp.Body 无 error 字段
- 时间条件必须用 RFC3339 格式（如
'2024-01-01T00:00:00Z'），不能用 Unix 时间戳或本地时间字符串 - 不支持
DELETE带GROUP BY或聚合函数，只能按时间+tag 过滤 - 若 measurement 名含空格或特殊字符，要用双引号包裹，如
"my cpu"
InfluxDB 2.x：必须用 influx delete API，Go 要构造 JSON body
2.x 的 DELETE 不是 SQL，而是按时间窗口批量标记删除，底层靠 TSM 文件重写实现，实际清理有延迟（通常几分钟到几小时）。
Go 中需手动构建 POST 请求体，例如删掉某 bucket 中 24 小时前的数据：
body := map[string]string{
"start": "1970-01-01T00:00:00Z", // 注意：2.x 要求 start 必须是 Unix epoch 或更早
"stop": "2024-01-01T00:00:00Z",
"predicate": "_measurement==\"cpu\"",
}
jsonBody, _ := json.Marshal(body)
req, _ := http.NewRequest("POST", "http://localhost:8086/api/v2/delete?org=my-org&bucket=my-bucket", bytes.NewBuffer(jsonBody))
req.Header.Set("Authorization", "Token my-super-secret-token")
req.Header.Set("Content-Type", "application/json")
-
start不能大于stop，且start若设为未来时间，请求会静默失败（返回 204 但无效果） -
predicate是 Flux 表达式语法，只支持_measurement、_field、tag 键，不支持正则或函数 - 没有权限时返回 401；bucket/org 名错返回 404；时间格式错返回 400 并带具体错误字段名
删完看不到数据？别急着重试，先查 _field_keys 和 SHOW RETENTION POLICIES
删除操作成功不代表立刻查不到——1.x 中 shard compact 未完成时，旧点仍可能被读出；2.x 中 delete marker 生效前，query 仍可返回已标记删除的数据（除非加 ignoreDeletes:true 参数）。
- 验证是否真删了：用
SELECT count(*) FROM "cpu"看行数变化，比SELECT *更可靠 - 删了数据但磁盘没释放？1.x 需手动运行
influxd-ctl compact-shard <shard-id>；2.x 依赖后台 compaction，无法手动触发 - 误删怎么办？1.x 只能从备份恢复；2.x 无回收站，
influx delete是不可逆的
最常被忽略的一点：InfluxDB 的「删除」本质是打标记或删文件，不是逐条擦除。如果你在压测后删数据却还看到 high cardinality 报警，大概率是 tag value 没清干净——那部分元数据不会随 DELETE 消失，得靠 DROP SERIES（1.x）或重建 bucket（2.x）来彻底清理。
