湿度数据看似简单，但存储和查询时有不少细节。传感器上报的每条记录至少包含时间、湿度读数，可能还有温度、设备编号。用SQLite落地这类数据，既能保持单文件易备份，又能通过SQL完成大部分分析，非常适合边缘设备或本地监控系统。
湿度监控通常包含多个传感器节点，每个节点定时上报数据。字段至少要包括传感器标识、采集时间和湿度值。为了后续扩展，可加上温度、电量或位置信息。设计表结构时，时间字段有两种选择：TEXT保存ISO 8601字符串，或者INTEGER保存Unix时间戳。前者可读性好，但排序和范围查询会涉及字符串转换；后者占用空间小，比较速度快，配合索引能显著提升时间筛选性能。
湿度本身用REAL类型存储足够。如果传感器精度只到整数，也可以用INTEGER，但REAL能保留小数，避免后期扩展精度时改动表结构。下面是建表SQL：
CREATE TABLE humidity_log (
id INTEGER PRIMARY KEY AUTOINCREMENT,
sensor_id TEXT NOT NULL,
ts INTEGER NOT NULL,
humidity REAL NOT NULL,
temperature REAL,
location TEXT
);
CREATE INDEX idx_humidity_sensor_ts ON humidity_log(sensor_id, ts);
CREATE INDEX idx_humidity_ts ON humidity_log(ts);
联合索引 sensor_id 加 ts 适合按设备查时间范围，单列 ts 索引适合全局时间排序和清理。如果写入量很大，索引会带来额外开销，但湿度监控通常以查询为主，这两个索引值得保留。
一、需求拆解与数据表设计
在实际部署中，传感器可能分布在客厅、卧室、地下室等不同位置，每个传感器有唯一编号。除了湿度读数，温度、电池电压也经常一起上报。把这些信息放在一张宽表里能减少关联查询，但会导致大量重复的传感器元数据。更规范的做法是拆成两张表：一张传感器信息表，一张湿度记录表。不过对于家用或小规模项目，单表配合 location 字段完全够用，维护成本更低。
时间戳的精度也值得考虑。如果传感器每5分钟上报一次，使用秒级Unix时间戳足够；如果后续要接入高频采集设备，可以换成毫秒级。SQLite的INTEGER是8字节有符号整数，范围足够覆盖到几百年后的时间。查询时可以用 datetime(ts, 'unixepoch', 'localtime') 转成可读格式，但要注意本地时区转换会依赖系统设置，跨机器迁移时最好统一存UTC，显示时再转换。
二、批量写入优化与WAL模式
单条插入在SQLite中会频繁触发fsync，写入速度可能只有每秒几十条。湿度数据虽然单条量不大，但传感器数量多、上报频率高时，累积下来的写入压力会很明显。解决办法是把多次insert放进一个事务，SQLite会延迟落盘，性能可提升两个数量级。Python标准库sqlite3提供了executemany方法，配合显式事务控制非常方便。
import sqlite3
import time
conn = sqlite3.connect("humidity.db")
cur = conn.cursor()
# 模拟批量数据，每个传感器1000条
samples = [
("sensor_01", int(time.time()) + i * 300, 55.2 + i * 0.1, 24.1, "living_room")
for i in range(1000)
]
# 显式开启事务，executemany内已使用同一事务
cur.executemany(
"INSERT INTO humidity_log(sensor_id, ts, humidity, temperature, location) "
"VALUES (?, ?, ?, ?, ?)",
samples,
)
conn.commit()
conn.close()
对于湿度数据，往往一边写入一边查询。默认的DELETE日志模式会让写阻塞读，如果有一个后台脚本正在持续写入，另一个查询任务就可能出现等待。开启WAL（Write-Ahead Logging）后，写操作写入单独的WAL文件，读操作仍可访问主数据库，并发体验更好。在首次连接数据库后执行 PRAGMA journal_mode=WAL; 即可，该设置会持久化在数据库文件中。同时可以把 synchronous 设为 NORMAL，减少同步频率。
PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL;
三、湿度数据查询与分析
存入数据后，最常见的查询是取某个传感器最近一段时间的平均湿度、最大最小值，以及超过阈值的时间段。时间戳用INTEGER，可以直接用数值比较，也可以配合 strftime 函数计算相对时间。例如要查最近24小时的聚合值，可以用 strftime('%s','now','-1 day') 得到起点的Unix时间戳。
-- 最近24小时平均湿度和最大湿度
SELECT
sensor_id,
AVG(humidity) AS avg_humidity,
MAX(humidity) AS max_humidity,
MIN(humidity) AS min_humidity
FROM humidity_log
WHERE ts >= strftime('%s', 'now', '-1 day')
GROUP BY sensor_id;
另一个实用场景是统计湿度超过80%的次数，或者找出连续高湿时段。SQLite支持窗口函数，可以计算相邻读数的差值，用来分析湿度变化率。比如某传感器在十分钟内湿度上升超过5个百分点，就可能是异常情况，需要触发检查。虽然SQLite的分析能力不如专业时序数据库，但数据量在百万级以内时完全够用。
-- 统计每个传感器湿度超过80%的记录数
SELECT sensor_id, COUNT(*) AS high_count
FROM humidity_log
WHERE humidity > 80.0
GROUP BY sensor_id;
-- 计算相邻读数的湿度变化
SELECT
sensor_id,
ts,
humidity,
humidity - LAG(humidity) OVER (
PARTITION BY sensor_id
ORDER BY ts
) AS delta
FROM humidity_log
WHERE sensor_id = 'sensor_01';
四、索引策略与数据维护
时间范围查询依赖 ts 索引。如果查询条件总是包含 sensor_id，那么联合索引 (sensor_id, ts) 比单独的 ts 索引更有效。但要避免在低基数字段如 location 上建索引，收益很小。对于湿度值本身通常不需要索引，因为对浮点数的等值匹配少，聚合扫描更常见。可以在项目运行一段时间后，用 EXPLAIN QUERY PLAN 查看查询计划，确认索引是否被正确使用。
随着数据增长，可以按天或按月创建分区表，或者定期删除过期数据。SQLite没有内置自动分区，但可以用触发器或定时脚本执行 DELETE。对于长期存储，建议按设备分表，或者使用 ATTACH DATABASE 将历史数据归档到单独文件。比如只保留最近90天的明细数据，更早的数据按月压缩成 CSV 或归档数据库。
-- 删除90天前的数据
DELETE FROM humidity_log
WHERE ts < strftime('%s', 'now', '-90 day');
备份非常简单，直接复制数据库文件即可，但在WAL模式下需要同时复制WAL文件，或先执行 PRAGMA wal_checkpoint;。另一个容易忽略的点是浮点数比较。湿度值来自传感器，可能带有微小误差，判断是否超过阈值时不要用等号，应使用范围如 humidity >= 80.0 和 humidity < 80.5 的组合逻辑，避免边缘数据被漏掉。综合这些策略，SQLite完全可以胜任中小规模的湿度数据存储与分析任务。