根本原因是外层WHERE或JOIN条件无法有效利用单列索引，必须用联合索引将时间字段与业务维度字段绑定；单列索引下B+树仅按一字段排序，无法支持“某设备在某时间段”的二维约束，优化器无法同时使用两个单列索引做交集扫描。
时序数据查询中嵌套查询性能差，根本原因不是子查询本身，而是外层 WHERE 或 JOIN 条件无法有效利用单列索引——必须靠联合索引把时间字段和业务维度字段“绑在一起”才能让优化器走索引。
嵌套查询里 time + device_id 这类组合条件为什么单列索引无效
比如常见写法：SELECT * FROM events WHERE device_id IN (SELECT device_id FROM devices WHERE status = 'active') AND event_time BETWEEN '2026-01-01' AND '2026-06-01'。即使 device_id 和 event_time 各自建了单列索引，MySQL 通常只选其一（多数选 event_time），导致先扫几百万行再过滤 device_id，执行计划里出现 Using where; Using temporary; Using filesort。
原因在于：单列索引无法表达“某设备在某时间段内”的二维约束，B+树只能按一个字段排序，device_id 索引里 event_time 是无序的，反之亦然。
- 优化器无法同时利用两个单列索引做“交集扫描”，尤其当子查询返回结果较多时，
IN会退化成循环匹配 -
BETWEEN是范围查询，若它出现在联合索引非最左位置（如(device_id, event_time)中event_time在右），仍可生效；但反过来(event_time, device_id)对device_id IN (...)就完全失效 - 子查询结果集越大，
IN的代价越高，而联合索引能直接把过滤下推到索引层
联合索引字段顺序怎么定：time 在前还是 device_id 在前
取决于外层查询的主导过滤模式。不是“时间最重要就放前面”，而是看哪个字段的筛选率更高、是否等值、是否在子查询中被确定。
- 如果子查询返回固定设备列表（如几十个
device_id），且外层总加event_time范围，优先用(device_id, event_time)—— 等值匹配device_id后，再对每个设备做event_time范围扫描，B+树局部有序性起作用 - 如果查询总是按时间切片（如查最近1小时所有设备），再筛设备类型，则用
(event_time, device_id)，但注意此时device_id IN (...)只能利用索引的第二层，效率略低，需配合STRAIGHT_JOIN或改写为JOIN - 避免
(event_time, tag)这类组合——tag选择性低（如只有 'ios'/'android'），会导致索引区分度骤降，实际效果不如单列event_time
覆盖索引能绕过嵌套查询的回表开销
当子查询只取 ID，外层又只查几个字段时，联合索引可以消除回表。例如：SELECT device_id, event_time, value FROM events WHERE device_id IN (SELECT id FROM devices WHERE type = 'sensor') AND event_time > NOW() - INTERVAL 1 HOUR。
建索引：CREATE INDEX idx_device_time_value ON events (device_id, event_time, value)。
- 索引包含全部 SELECT 字段 + WHERE 条件字段，执行计划显示
Using index，不访问聚簇索引页 - 子查询结果被当作常量集合，
device_id等值匹配后，event_time范围扫描直接输出value，无需回表查整行 - 注意：
value若是 TEXT 或 BLOB 类型，不能建在索引中，此时覆盖失效，得换字段或加前缀长度
真正卡住性能的往往不是子查询语法，而是索引没把时间维度和实体维度“焊死”在同一个 B+ 树路径上。建错顺序的联合索引，比不建还误导优化器——它看似走了索引，实则扫描了整个时间分片下的所有设备数据。
