TSDB 工作负载同时受写入量、单批大小、Tag 基数、列数量、查询范围和保留周期影响。不要只根据原始数据字节数选择规格。当前建议通过测试基线确定初始规格，上线后结合监控指标，通过变配与扩缩容调整配置。

如需了解不同规格在车联网、物联网和服务器监控场景下的实测读写表现，请参见性能测试报告。

建立业务基线

在测试集群中使用具有代表性的数据和查询，记录：

• 峰值与平均写入请求 QPS、写入行数和写入吞吐。
• 单次写入的平均行数和最大请求体。
• 数据库、表、Tag、Field 和序列增长速度。
• 查询并发、扫描时间范围、结果集大小和平均延迟。
• Retention 下的存储增长趋势。

Schema 建议

• 把常用于筛选和分组、且取值集合可控的属性设计为 Tag。
• 不把请求 ID、随机字符串或持续增长的唯一值设计为 Tag。
• 规划 Tag 顺序时，将区分度最高且最常用于精确筛选的 Tag 放在 Line Protocol 的 Tag 列表首位。例如在 IoT 场景中，deviceId 的单个取值通常只对应一台设备，比地域或机房等 Tag 能将查询范围缩小到更少的数据，因此按设备查询时可以获得更好的数据裁剪效果。Tag 顺序在首次写入建表时确定，后续调整 Line 中的 Tag 顺序不会改变已有 Table；详细说明请参见数据模型与权限。
• 保持同名 Field 的类型稳定。
• 不通过动态列名表达业务值，避免快速消耗列数量上限。
• 按业务和权限边界规划数据库，不为每个设备创建数据库。

持续观察

上线后结合业务指标和节点指标观察容量变化。变配或扩缩容前，用高峰期数据验证目标配置；变更后重新核对写入、查询和资源使用基线。