直接查原始物联网表会卡住因全表扫描，响应超2s；应建索引、用物化视图（PostgreSQL）或连续聚合（TimescaleDB），避开DISTINCT ON、DATE函数、未四舍五入浮点聚合，并规范字段命名为time/device/metric_name。
为什么直接查原始物联网表会让前端卡住
原始设备数据表通常每秒写入成百上千条记录，字段包含 device_id、timestamp、temperature、humidity 等，没索引或分区时，SELECT * FROM raw_data WHERE timestamp > NOW() - INTERVAL '5 minutes' 这类查询会扫全表，响应常超 2s。视图本身不存数据，但能固化常用过滤+聚合逻辑，让下游只查“结果快照”。
用物化视图（PostgreSQL）还是普通视图（MySQL）
关键看实时性要求和数据库支持：
- PostgreSQL 9.4+ 支持
CREATE MATERIALIZED VIEW，可定期REFRESH MATERIALIZED VIEW，适合秒级延迟可接受的场景（如大屏每 10 秒刷新一次） - MySQL 没原生物化视图，只能用普通视图 + 合理索引，或靠应用层缓存；但普通视图每次执行都重算，若聚合涉及
GROUP BY device_id, time_bucket('1min', timestamp)，必须确保timestamp和device_id有联合索引，否则照样慢 - TimescaleDB（基于 PG）推荐直接用
continuous aggregate，它自动按时间窗口维护预计算结果，比手动刷物化视图更省心
视图里必须避开的三个聚合陷阱
物联网数据高频写入，视图定义稍不注意就会拖垮整个库：
- 别在视图里用
SELECT DISTINCT ON (device_id) *取最新一条——没索引时等价于全表排序，改用ROW_NUMBER() OVER (PARTITION BY device_id ORDER BY timestamp DESC)+ 外层过滤 - 避免跨天聚合用
DATE(timestamp)，它无法利用timestamp索引；换成time_bucket('1day', timestamp)（TimescaleDB）或timestamp::date（PG，需函数索引） - 温度/湿度这类浮点字段，聚合后别裸用
AVG()，加ROUND(AVG(temperature), 2)减少传输体积，也避免前端 parseFloat 精度抖动
给 Grafana 配视图时的关键字段命名规则
Grafana 的 PostgreSQL 数据源默认把列名当指标名，如果视图返回 avg_temp、max_hum 这种缩写，面板里就得手动改别名；不如一步到位：
- 时间字段统一叫
time（Grafana 自动识别），别用ts或event_time - 设备标识固定为
device，不是device_id或dev_code，方便变量下拉选值复用 - 数值列用
metric_name格式，比如temperature_celsius、humidity_percent，Grafana tooltip 里直接显示单位 - 示例视图定义片段：
CREATE VIEW v_device_1min_stats AS SELECT time_bucket('1 minute', timestamp) AS time, device_id AS device, ROUND(AVG(temperature), 2) AS temperature_celsius, ROUND(MAX(humidity), 1) AS humidity_percent FROM sensor_readings WHERE timestamp > NOW() - INTERVAL '1 hour' GROUP BY 1, 2;
视图不是银弹——设备突然断连时，time_bucket 会产生空时间片，得靠 Grafana 的 Null value 设置补零，或者在视图里用 generate_series 做左连接，这部分容易被忽略，但直接影响曲线连续性。
