ClickHouse TTL 不适合微服务归档，因其仅支持自动删除、无迁移校验能力、触发不可控且缺乏业务维度策略；应采用 HTTP 流式导出 + ATTACH PARTITION 实现可控冷数据搬移，注意时区处理、TSV 解析、ORDER BY 优化及断点续传设计。
ClickHouse TTL 不适合微服务归档场景
直接用 TTL 做归档不可靠。它只控制数据自动删除，不提供迁移、校验、回溯能力；TTL 触发时机不可控，且无法按业务维度（如租户、事件类型）差异化策略。微服务中一旦误删或归档逻辑出错，几乎没有补救手段。
用 HTTP 流式导出 + 分区 ATTACH 实现可控归档
归档本质是“冷数据搬移”，不是删除。最稳妥的做法是：查出待归档数据 → 导出为本地文件 → 写入归档表（带 ENGINE = MergeTree() 且无 TTL）→ 用 ATTACH PARTITION 加载到归档库。整个过程必须绕过高层封装，用 http.Client 直连：
- 构造 URL 必须含
&format=TabSeparatedWithNamesAndTypes&stream=1，避免 JSON 解析开销 - 响应体是 TSV，首行为字段名+类型（如
ts\tDateTime64(3, 'UTC')\n），需跳过第一行再逐行解析 - 写入归档表时，
INSERT INTO archive_table FORMAT TSV要显式指定SETTINGS input_format_skip_unknown_fields = 1，防止字段新增导致失败 - 归档表建表语句里务必加
ORDER BY (tenant_id, ts)，否则后续按租户查询会慢十倍以上
时间字段处理不当会导致归档漏数据
微服务常按 tenant_id 和 ts 归档，但 DateTime64(3, 'UTC') 在 Go 里解析容易出错：
- 别用
time.Parse("2006-01-02", "2024-01-01")—— 默认走本地时区，和 ClickHouse UTC 存储值对不上 - 正确做法是：
t := time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC)，然后格式化为t.Format("2006-01-02 15:04:05.000") - WHERE 条件必须写成
ts >= toDateTime64('2024-01-01 00:00:00.000', 3, 'UTC')，不能依赖参数绑定，因为驱动对 DateTime64 的参数映射不稳定
归档任务失败后如何安全重试
HTTP 流式导出中途断连很常见，但 ClickHouse 不支持断点续传。必须在归档前先记下最小/最大 ts 和行数：
立即学习“go语言免费学习笔记（深入）”；
- 先执行
SELECT min(ts), max(ts), count() FROM logs WHERE ...获取范围与总量 - 导出时把
min(ts)和count()记入本地 SQLite 或 Redis，作为 checkpoint - 重试时用
WHERE ts > ? AND ts 切片重跑，避免重复归档 - 归档完成后，用
SELECT count() FROM archive_table WHERE ts BETWEEN ? AND ?校验数量是否一致，不一致就报警而不是静默跳过
归档不是后台定时任务，而是有状态、可验证、可回滚的数据操作。任何跳过校验、忽略时区、依赖自动 TTL 的设计，在微服务多实例并发场景下都会出问题。
