子查询必须关联设备表和心跳日志表，正确做法是用order by timestamp desc limit 1取每台设备最新心跳并比对当前时间，注意时区统一、避免null陷阱及性能问题。
子查询必须关联设备表和心跳日志表
直接在 WHERE 里写 (SELECT MAX(timestamp) FROM heartbeats WHERE device_id = devices.id) 是常见错误——它没加时间约束，查出来的可能是几天前的旧记录，导致误判“超时”。正确做法是让子查询只查最近一次心跳，并与当前时间比对。
- 用
INNER JOIN或相关子查询，确保每台设备只取其最新一条心跳记录 - 子查询中必须带
ORDER BY timestamp DESC LIMIT 1（MySQL/PostgreSQL）或TOP 1（SQL Server），否则结果不确定 - 注意时区：平台时间、数据库服务器时间和设备上报时间是否统一，不一致会导致
NOW() - timestamp > INTERVAL '5 minutes'判定失准
避免子查询被重复执行导致性能暴跌
如果写成 SELECT * FROM devices WHERE (SELECT MAX(timestamp) FROM heartbeats WHERE device_id = devices.id) ，数据库可能对每行设备都执行一次子查询，心跳表越大越慢。尤其当设备数超万、心跳日志每天千万级时，响应会从毫秒变秒级。
- 改用
LATERAL（PostgreSQL）或APPLY（SQL Server）把子查询转为连接操作，强制先算最新心跳再关联 - MySQL 8.0+ 可用
ROW_NUMBER() OVER (PARTITION BY device_id ORDER BY timestamp DESC)预计算排名，再过滤 rank=1 的记录 - 务必给
heartbeats(device_id, timestamp)建联合索引，否则子查询走全表扫描
处理设备从未上报过心跳的“幽灵设备”
纯 INNER JOIN 会漏掉从没发过心跳的设备，但这类设备也属于“超时”范畴（上线即失联）。这时候不能依赖子查询返回值做比较，得用 LEFT JOIN + IS NULL 或 NOT EXISTS。
-
NOT EXISTS更清晰：NOT EXISTS (SELECT 1 FROM heartbeats h WHERE h.device_id = d.id AND h.timestamp > NOW() - INTERVAL '5 minutes') - 若用
LEFT JOIN，需在ON条件里就限定时间范围：ON h.device_id = d.id AND h.timestamp > NOW() - INTERVAL '5 minutes'，再查h.device_id IS NULL - 注意 NULL 陷阱：
MAX(timestamp)对无记录设备返回 NULL，而NULL 结果为 UNKNOWN，不是 TRUE，所以不能直接拿聚合结果判断
不同数据库对时间函数的写法差异很大
写死 NOW() 在 PostgreSQL 里没问题，但在 MySQL 里可能因时区配置返回系统时间而非 UTC；SQLite 根本没有 NOW()，得用 datetime('now')；Oracle 要用 SYSDATE。子查询里的时间运算一旦写错，整个超时逻辑就失效。
- PostgreSQL：
timestamp - MySQL：
timestamp （确认 <code>time_zone设为 '+00:00' 或与设备时区一致） - SQLite：
timestamp ，且字段必须是 TEXT 或 REAL 类型才能参与比较 - 别用
UNIX_TIMESTAMP()手动算秒数——浮点精度误差、夏令时切换时容易出错
实际部署前，一定用真实心跳数据跑一遍，检查刚断连的设备是否 5 分钟内出现在结果里，以及断电超过 24 小时的设备是否仍被包含——边界情况比语法更难测。
