大量设备查询¶

单元 14｜难度：中级｜前置：数据库、Redis、在线状态｜目标：按列表、统计、导出和实时推送分别设计

先澄清“大量查询”是哪一种¶

不同需求不能使用同一个方案：

错误思路：

数据库加载 100,000 台设备
  → Redis 读取 100,000 个状态
  → 应用组装所有对象
  → 返回浏览器

正确思路：

数据库读取一页 100 台设备
  → MGET/HMGET 读取本页状态
  → 应用按 ID 合并
  → 返回 100 条

应用层确实需要暂存数据库结果、Redis 结果和响应对象，但对象数量由页大小控制。真正危险的不是“应用层组装”，而是：

LIMIT 100 OFFSET 1000000 可能越来越慢，因为数据库仍需跳过大量记录。

更适合使用基于稳定排序键的游标分页：

SELECT id, name, model
FROM devices
WHERE tenant_id = :tenant_id
  AND id > :last_id
ORDER BY id
LIMIT 100;

需要为过滤与排序模式设计合适索引。

不要为了一个数字装载所有设备。可以：

全量导出不是普通同步 HTTP 列表请求：

这既控制内存，也避免请求超时。

我实际项目没有达到百万设备，但处理大量设备查询时会先区分列表、统计和全量任务。列表采用数据库游标分页，并对本页设备从 Redis 批量读取实时状态；统计读取预计算结果；全量导出则转为异步任务分批处理。这样不会把十万设备一次性加载到应用内存。