> 一台设备每 5 秒上报一次，一天就是 17280 条。100 台设备一天 172 万条，一个月 5000 万条。能收到数据只是第一天，第二天开始真正的难题是：这张表怎么查得动、怎么清得掉。本文用我正在搭的设备接入平台里的真实代码，把"时序数据治理"这条线讲透。

## 先算一笔账：你为什么一定会遇到这个问题

设备接入层跑通之后，很多人会松一口气——数据能进来、能展示，故事结束了。

但把上报频率代进去就不那么乐观了：

| 设备数 | 上报频率 | 单日条数 | 单月条数 |
| --- | --- | --- | --- |
| 1 台 | 5 秒一次 | 17,280 | 约 52 万 |
| 100 台 | 5 秒一次 | 172.8 万 | 约 5184 万 |
| 1000 台 | 5 秒一次 | 1728 万 | 约 5.2 亿 |

**遥测数据是典型的时序数据：只涨不缩。** 它没有"删除"这个业务动作，设备只要活着就一直上报。所以等你发现 `/api/devices/{id}/data` 从 7ms 变成 2 秒，通常表已经几千万行了。

这就是设备接入平台从 M2 走到 M3 时必须补上的一课。下面三块，对应"怎么清、怎么查、怎么证明"。

## 一、怎么清：分批删除，别一条 DELETE 干到底

最直觉的写法是一句 SQL 清掉 30 天前的数据：

```bash
-- 千万别这么写
DELETE FROM data_point WHERE received_at < NOW() - INTERVAL 30 DAY;
```

这句话在开发机上跑得飞快，在有几千万行业务表上就是事故：一个大事务会长时间持锁、undo log 暴涨、binlog 写满、主从延迟飙到几分钟，期间线上查询全部排队。

正确做法是**分批删**。这是我项目里的真实实现：

```bash
@Slf4j
@Component
@RequiredArgsConstructor
public class DataRetentionJob {

    public static final int BATCH_SIZE = 1000;

    private final DataPointRepository dataPointRepository;

    /** 保留天数，application.yml 里 iot.data-retention.days 可覆盖 */
    @Value("${iot.data-retention.days:30}")
    private int retentionDays;

    /** 真正的清理逻辑，返回删除的总行数。public 是为了单元测试直接调用 */
    public int purgeExpired(int days) {
        Instant cutoff = Instant.now().minus(days, ChronoUnit.DAYS);
        int total = 0;
        int batch;
        do {
            List<DataPoint> oldest = dataPointRepository
                    .findTop1000ByReceivedAtBeforeOrderByIdAsc(cutoff);
            batch = oldest.size();
            if (batch > 0) {
                dataPointRepository.deleteAllInBatch(oldest);
                total += batch;
            }
        } while (batch == BATCH_SIZE); // 删满一批说明可能还有，继续；没删满说明清完了
        if (total > 0) {
            log.info("数据保留任务：删除 {} 天前的遥测数据 {} 条（截止 {}）", days, total, cutoff);
        }
        return total;
    }

    /** 生产节奏：每天凌晨 3 点执行。单实例部署暂不需要分布式锁 */
    @Scheduled(cron = "${iot.data-retention.cron:0 0 3 * * ?}")
    public void run() {
        purgeExpired(retentionDays);
    }
}
```

这段代码里有 5 个点是面试真能聊的：

1.  **分批而不是全删**。每批 1000 条，一个短事务一把梭完就提交，锁持有时间毫秒级，不会打扰线上流量。
2.  **`while (batch == BATCH_SIZE)` 这个循环条件是关键**。删满一批说明"可能还有"，继续；没删满说明已经清空，退出。比"先 count 再算循环次数"省一次全表扫描。
3.  **保留天数走配置**。`iot.data-retention.days` 默认 30，不同环境可以不一样（测试环境保留 3 天就够）。硬编码天数是很多人的第一版写法，改起来要重新发版。
4.  **cron 也走配置，默认凌晨 3 点**。清理是低优先级任务，要避开业务高峰。
5.  **只删 `data_point`，`device` 档案永远保留**。一句话原则：**数据会过期，档案不会。** 设备表是业务实体，删了就等于设备"消失了"，历史数据全成孤儿。

如果要更进一步，接着做这三步：`received_at` 上加索引（否则这个查询本身就在全表扫）、按时间分区表（`PARTITION BY RANGE`，删数据直接 `DROP PARTITION`，秒级完成）、上量后换成 TDengine 这类时序库（自带 retention 策略，连定时任务都省了）。

## 二、怎么查：索引 + 限量 + 不许深分页

清理解决"存得下"，查询决定"用起来"。时序表的查询有三条铁律。

**第一条：`deviceId + receivedAt` 必须有索引。** 时序表是全库最大的表，没有索引的时间范围查询就是灾难。我的实体上先建了设备维度索引：

```bash
@Entity
@Table(indexes = @Index(name = "idx_datapoint_device", columnList = "deviceId"))
public class DataPoint {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long deviceId;
    private String productKey;

    /** 原始 JSON，如 {"temp":25.5,"humi":60} */
    @JsonIgnore
    private String payload;

    /** 服务端收到的时间 */
    private Instant receivedAt;
}
```

注意 `payload` 上是 `@JsonIgnore`——**别把原始 JSON 大字段顺手塞进列表接口的响应里**。这是个很容易犯的错：一个设备 100 条数据，每条 payload 200 字节，响应就凭空多出 20KB，网络和前端渲染全被拖慢。

**第二条：接口必须限量，且要有硬上限。** 设备上报是无界的，全量查询一定会把内存打爆：

```bash
private static final int DEFAULT_LIMIT = 100;
private static final int MAX_LIMIT = 1000;

int size = limit == null ? DEFAULT_LIMIT : Math.min(limit, MAX_LIMIT);
Pageable pageable = PageRequest.of(0, size, Sort.by(Sort.Direction.DESC, "id"));
return views(dataPointRepository.findByDeviceId(deviceId, pageable));
```

`Math.min(limit, MAX_LIMIT)` 这一句是整个接口最重要的防线。如果有人传 `limit=999999`，你不拦住，数据库就得把整张表捞出来。**开放给外部调用的分页参数，一定要有服务端上限。**

**第三条：返回倒序，且不给深分页。** 我的接口默认返回最新 100 条而非最旧 100 条——看板要画的是"最近的曲线"，`limit=100` 就该拿到最新的 100 条。同时接口只做"最新 N 条"和"时间范围查询"，**故意不做 offset 深分页**：`LIMIT 1000000, 100` 这种查询 MySQL 要扫前面 100 万行，越翻越慢。历史数据要靠时间范围定位，不是靠翻页。

时间范围参数还要做格式校验，别让非法输入变成 500：

```bash
private Instant parse(String value, String param) {
    try {
        return Instant.parse(value);
    } catch (DateTimeParseException e) {
        throw new IllegalArgumentException(
                param + " 需要 ISO-8601 格式，例如 2026-09-22T00:00:00Z");
    }
}
```

配合全局异常处理，这个 `IllegalArgumentException` 会变成 `400 + 明确提示`，用户拿到的是"参数格式不对"，而不是"服务器内部错误"。

## 三、怎么证明：压测要看分位数，不是平均数

代码写完了，"性能好"不能靠感觉，得压。我对最热的查询接口 `GET /api/devices/{id}/data?limit=100` 做了基准压测（JMeter 5.6，100 并发线程、20 秒 ramp-up、持续 60 秒）。**先说清环境：压测端、应用、MySQL 全在同一台开发笔记本上**，这是个诚实但很受限的条件。

实测结果（我记录在 `loadtest/README.md` 里）：

| 指标 | 数值 |
| --- | --- |
| 总请求数 | 136,892 |
| 实际时长 | 59.9 s |
| **吞吐量** | **2,285 req/s** |
| 平均响应 | 36.5 ms |
| P50 | 7 ms |
| P90 | 104 ms |
| P95 | 191 ms |
| **P99** | **422 ms** |
| 最大 | 1,712 ms |
| **错误率** | **0.00%** |

比数字更重要的是怎么读这组数字，这里有两个反直觉的点：

**第一，瓶颈不在服务端。** 100 线程 × 平均 36.5ms ≈ 理论上限 2700 req/s，实测 2285 req/s，逼近这个天花板了。这说明瓶颈是"压测端的并发模型"，不是我的接口——服务端还远没打满。想压出服务端真实极限，得把 JMeter 放到另一台机器上。

**第二，P50 和 P99 差了 60 倍。** P50 只有 7ms，P99 却是 422ms。长尾从哪来？GC 停顿 + JMeter 和被测应用抢同一台机器的 CPU。**如果只报"平均响应 36.5ms"，这条长尾就被平均数完全掩盖了。** 面试被问"你的接口性能如何"，回答"平均 36ms"基本等于没回答；回答"P50 7ms、P99 422ms，长尾来自 GC 和压测端同机抢核，所以我下一步要分离压测机"——这才是做过压测的人。

## 读者常见三问

**Q：为什么不用 `DELETE ... LIMIT 1000` 这样一句 SQL 批量删，非要先查出来再删？**

A：`DELETE ... LIMIT` 在 MySQL 单表上可以用，但有两个现实问题：一是有 `LIMIT` 的 `DELETE` 在部分场景（多表、有外键、需要主从一致）支持不佳；二是先 `SELECT` 出主键列表再按主键删，主从复制更安全，而且这个 `SELECT` 走索引、结果可预测。我选的是后者。**关键从来不是选哪种语法，而是"别让一个事务删几百万行"这个原则本身。**

**Q：分批删除会不会删到一半失败，留下不一致状态？**

A：不会。每一批是独立事务，删掉的就是真删掉了，剩下的下一轮继续删——**最终一致**。清理任务不需要 ACID 跨批事务，因为它本来就是个"幂等的收敛过程"。真出异常，第二天凌晨 3 点还会再来一次。

**Q：什么时候该放弃 MySQL，换 TDengine / TimescaleDB？**

A：三个信号同时出现就该换了：① 单表超过 1 亿行；② 查询从"某设备最近数据"变成"多设备跨时间聚合"（比如按小时算平均值）；③ 你开始手写分区、归档、降采样这些时序库自带的功能。**换成时序库之后，接口层几乎不用改**——这也是为什么我从一开始就把查询包在 `DataPointView` 这种 DTO 里，而不是把实体直接抛出去。

## 下一步

到这里，设备接入平台的"数据侧"闭环了：接入 → 入库 → 限量查询 → 定时清理 → 压测验证。再往后是两件事：一是把数据量堆上去，用分区表或 TDengine 重跑同一份压测脚本，看拐点在哪；二是做规则引擎和告警，这才是物联网平台真正产生业务价值的地方。

---

*我是软件工程在读，正在从零搭一个物联网设备接入平台（Spring Boot + EMQX + MySQL），所有代码和踩坑记录都会发出来。欢迎关注，一起卷物联网后端。*

一台设备每 5 秒上报一次，一天就是 17280 条。100 台设备一天 172 万条，一个月 5000 万条。能收到数据只是第一天，第二天开始真正的难题是：这张表怎么查得动、怎么清得掉。本文用我正在搭的设备接入平台里的真实代码，把"时序数据治理"这条线讲透。

物联网平台数据表只涨不缩？Spring Boot 遥测数据保留策略：分批删除 + 索引优化 + 真实压测数据

数据库

后端

物联网

设备时序数据治理核心策略：分批删除+索引优化+限量查询+压测验证。实测P50 7ms、P99 422ms，吞吐2285req/s，零错误率。清理采用1000条/批短事务，避免锁表；查询强制limit上限并禁用深分页；性能瓶颈识别关注分位数而非平均值。

数据治理

软件工程

单元测试

代码解释

服务器

MySQL

JSON

腾讯云数据库特惠，新用户首单0.5折起


2026上云采购 | AI焕新·智启新局

iot-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

物联网平台数据表只涨不缩？Spring Boot 遥测数据保留策略：分批删除 + 索引优化 + 真实压测数据-腾讯云开发者社区-腾讯云

物联网平台数据表只涨不缩？Spring Boot 遥测数据保留策略：分批删除 + 索引优化 + 真实压测数据

物联网平台数据表只涨不缩？Spring Boot 遥测数据保留策略：分批删除 + 索引优化 + 真实压测数据

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐