short压缩时序数据的核心是匹配数据范围并规避隐式膨胀，在温度、湿度等窄波动IoT场景中可将存储压至原int/float的1/2~1/4，零成本优化。
用 short 类型压缩低精度时序数据，核心在于“匹配数据范围”和“规避隐式膨胀”。它不是通用解法，但在温度、湿度、电压等变化平缓、波动窄的IoT场景中，能直接将存储开销压到原 int 或 float 的 1/2 甚至 1/4，无需算法、不增延迟，属于零成本内存优化。
明确 short 的能力边界
short 是有符号 16 位整数，取值范围为 -32768 到 32767。这意味着：
- 若原始传感器数据以摄氏度为单位，精度要求到 0.1℃，实测范围在 -40℃ ~ +85℃ 之间，可先放大 10 倍转为整数：-400 ~ +850 → 完全落在 short 范围内；
- 若原始是 0~5V 模拟量，ADC 分辨率 12 位（0~4095），直接存入 short 不仅够用，还留有余量；
- 但若数据含小数且需保留 0.001 精度，或峰值超 ±32k，就不能硬套 short，否则溢出或截断失真。
嵌入式端采集层直接类型对齐
避免“先 float 采集 → 再转 int → 再存 short”的三步跳，从源头固化类型：
- 在 MCU 固件中，ADC 读取后不做 float 运算，直接按比例缩放并强制转为 int16_t（C/C++ 中 short 的标准别名）；
- 禁用浮点运算库（如
-mno-fpu编译选项），消除隐式类型提升带来的栈开销； - 使用位域或结构体打包多个 short 字段，例如：
struct { int16_t temp; int16_t humi; int16_t volt; } sample; —— 单条记录仅占 6 字节，比三个float（12 字节）省一半。
服务端接收与存储链路适配
端侧压缩了，服务端必须保持一致，否则等于白干：
- MQTT Payload 或 HTTP Body 中，用二进制格式（非 JSON 文本）传输 raw short 数组，避免字符串解析开销；
- 数据库字段定义为
SMALLINT（PostgreSQL/MySQL）或int16（TimescaleDB），禁用自动类型提升； - Java 后端接收时用
ByteBuffer.getShort()直接读，不走Integer.valueOf(String)这类包装转换。
配套时间戳压缩进一步降载
单靠数值压缩不够，时间维度同样关键：
- 放弃每条记录存完整 64 位毫秒时间戳（8 字节），改用“基准时间 + delta 差值”；
- 若采样间隔固定为 1 秒，delta 可用 short 存秒偏移（最大支持 ±32767 秒 ≈ 9 小时），再配合 4 字节基准时间（如起始 Unix 时间戳）；
- 组合后单条记录：2 字节（时间差）+ 2×2 字节（两个 short 数据）= 6 字节，相较传统 8+4+4=16 字节，压缩率达 62.5%。
