时序数据库的写入优化已被广泛讨论——列式存储、无锁追加、批量写入——这些技术的成熟度已经很高。但查询优化得到的关注远不如写入。实际项目中，写入瓶颈少见，查询慢的抱怨多。一个存储了6个月数据、10万测点的存储系统，写入毫无压力，但查"过去一个月所有产线温度日均值"可能要等30秒甚至更久。查询性能不达标，时序数据库的价值就打折扣。优化时序查询需要理解查询模式、定位瓶颈、选择正确的优化手段。
时序查询的四种典型模式
时序查询不是随机查询，其模式高度可分类。理解查询模式是优化的起点。
最新值查询（Last Query） 返回某测点或某组测点的当前值。典型SQL：SELECT LAST(temperature) FROM sensor_temp GROUP BY device_id。这种查询在实时监控看板中高频出现，每几秒刷新一次。性能要求：毫秒级返回。
时间范围查询（Range Query） 返回某测点在指定时间范围内的所有数据点。典型SQL：SELECT * FROM sensor_temp WHERE ts > '2024-01-01' AND ts < '2024-01-02' AND device_id = 'D001'。用于趋势曲线展示和故障回溯。性能要求：小范围（1天内）秒级返回，大范围（30天）十秒级返回。
聚合查询（Aggregation Query） 对时间范围内的数据做统计计算。典型SQL：SELECT AVG(temperature), MAX(temperature), MIN(temperature) FROM sensor_temp WHERE ts > '2024-01-01' AND ts < '2024-02-01' GROUP BY device_id。用于日报表、月报表和趋势分析。性能要求：分钟级返回可接受。
降采样查询（Downsampling Query） 将高频数据按粗粒度时间窗口聚合后返回。典型SQL：SELECT AVG(temperature) FROM sensor_temp WHERE ts > '2024-01-01' AND ts < '2024-02-01' INTERVAL(1h)。用于大时间范围趋势展示——1秒采样的数据画30天趋势图不需要86400×30=259万个点，降采样到每小时1个点只需720个点。性能要求：十秒级返回。
查询类型 | 典型场景 | 数据扫描量 | 性能要求 | 核心瓶颈 |
最新值查询 | 实时看板 | 1条/测点 | <100ms | 全表扫描取最后值 |
时间范围查询 | 趋势曲线/故障回溯 | 千-百万条 | <5s | 大范围数据解压 |
聚合查询 | 日报/月报 | 百万-亿条 | <60s | 全量扫描计算 |
降采样查询 | 长周期趋势 | 百万-亿条 | <10s | 大窗口聚合计算 |
查询性能瓶颈定位
查询慢的原因不在一个点上。四个常见瓶颈各自需要不同的优化手段。
全表扫描是最常见的瓶颈。没有合适索引的查询不得不扫描整个数据集。查"某工厂所有温度传感器昨天的均值"如果数据库不能按工厂标签快速定位到相关子表，就要扫描所有温度子表的数据——包括其他工厂的——然后过滤。这在测点数量大的系统中性能灾难。
大范围时间查询内存溢出。查30天全量数据，如果每秒1条、10000个测点，数据量25.9亿条。即使压缩存储，解压后在内存中聚合计算也需要大量内存。查询引擎可能因内存不足而终止或使用磁盘临时文件，后者性能断崖式下降。
标签过滤效率低。时序数据库的标签索引如果设计不当——例如标签基数过高导致索引膨胀，或标签组合未建联合索引——过滤操作退化为扫描。查"某变电站某间隔所有测点"如果变电站标签和间隔标签没有联合索引，可能先按变电站过滤出大量数据再逐条匹配间隔。
聚合计算无预计算。每次查询都从原始数据做聚合，重复计算量大。如果"每小时温度均值"这个查询每天被调用100次，每次都扫描1小时的原始数据（3600条/测点×10000个测点=3600万条）做计算。预计算一次写结果表，后续查询直接读结果表，扫描量降3600倍。
优化策略一：标签索引加速设备过滤
标签索引是时序数据库中"设备过滤"的核心加速手段。当查询条件包含标签过滤（WHERE substation_id = 'S001' AND bay_name = 'B01'），标签索引将相关子表的查找从全表扫描降为索引查找。
TDengine的标签索引采用B+树结构，对标签值建立索引。标签值在子表创建时确定，索引在写入时维护。查询时根据标签条件从索引树定位到匹配的子表集合，再从这些子表读取数据。关键在于：数据读取只涉及匹配的子表，不匹配的子表完全不读取。
索引设计的工程要点：高频查询的标签组合应建联合索引。如果查询经常同时过滤变电站+间隔+设备类型，这三个标签的联合索引比三个单标签索引的查询效率高一个数量级。但联合索引的列顺序很重要——选择性最高的标签放前面。变电站标签选择性高（一个变电站下的子表占比通常<5%），设备类型标签选择性低（一个设备类型的子表占比可能>50%），顺序应为变电站→间隔→设备类型。
标签基数控制对索引性能影响显著。标签基数过高的典型是设备ID标签——10万个设备ID意味着10万条索引项。B+树索引项本身的内存占用约几十字节到上百字节每项，10万项约几MB，尚可接受。但如果设备ID达到百万级，索引内存占用显著。实践中应控制单超级表的标签基数在十万级以内，超过这个规模应考虑拆分超级表。
优化策略二：连续查询预计算聚合
连续查询（Continuous Query, CQ）是时序数据库内置的预计算机制。其原理是：按固定周期自动执行聚合查询，将结果写入预计算结果表。后续查询直接读取结果表，不需要对原始数据做实时聚合。
TDengine的连续查询配置示例：每5分钟自动计算各测点过去5分钟的温度均值、最大值、最小值，写入结果表sensor_temp_5m。查询"昨天每5分钟温度趋势"时直接查sensor_temp_5m，而非扫描原始表。
连续查询的设计要点在于粒度选择。预计算粒度越细，结果表数据量越大但查询灵活性越高；粒度越粗，数据量越小但灵活性越低。工程实践中的常见策略是配置多级连续查询：5分钟级、1小时级、1天级三级预计算。5分钟级满足实时趋势查询，1小时级满足日报查询，1天级满足月报和年报查询。每级结果表数据量是上一级的1/12或1/24。
连续查询的代价是写入CPU开销和存储空间。每个连续查询周期触发一次聚合计算，计算量与测点数量和聚合函数数量成正比。10万测点×3个聚合函数×5分钟周期，每5分钟做30万次聚合计算，CPU开销在可接受范围（单节点几秒内完成）。存储空间方面，结果表数据量是原始表的1/300（5分钟降采样），存储成本增量很小。
优化策略三：降采样查询
降采样查询是大时间范围查询的核心优化手段。其原理简单：用INTERVAL()子句将高频数据按粗粒度窗口聚合，大幅减少返回数据量。
查30天数据，原始数据1秒一条×10000个测点=25.9亿条。如果展示趋势曲线，屏幕分辨率1920×1080，横轴最多显示1920个点。25.9亿条数据画1920个点，每个点代表135万个原始数据——完全可以用降采样到30分钟一个点（1440个点）替代。SQL中使用INTERVAL(30m)，聚合函数用AVG，数据量从25.9亿条降到1440条，查询时间从几十秒降到几百毫秒。
降采样查询的关键在于粒度自适应。应用层应根据查询时间范围动态选择降采样粒度：1小时范围用原始数据（不降采样）；1天范围用1分钟粒度；30天范围用30分钟粒度；1年范围用1天粒度。这种自适应策略保证不同范围查询都有可接受的响应时间。
优化策略四：分区裁剪
时序数据按时间分区存储，每个分区（TDengine中称为文件块/data block）包含一个时间范围的数据。分区裁剪是指查询时根据时间条件跳过不相关的分区，只扫描匹配的分区。
查"昨天0点到今天0点"的数据，数据库按天分区时只需要扫描昨天那一个分区，其他364天的分区完全不读取。分区裁剪在引擎层自动完成——查询执行器根据WHERE子句的时间条件计算涉及的分区列表，只读取这些分区的数据。
分区大小影响裁剪效率。分区过小（如1小时一个分区）导致分区数量多，元数据开销大；分区过大（如1个月一个分区）导致裁剪粒度粗，查询1天数据可能要读取整个月的分区。TDengine默认按天分区（可通过参数调整），对于大多数工业场景是合理的选择——查日级、周级报表时分区裁剪效率高。
执行计划分析与慢查询定位
优化不能靠猜。TDengine提供EXPLAIN命令输出查询执行计划，包括：标签过滤路径（走了哪些索引）、时间分区裁剪范围、数据扫描行数、聚合计算方式。通过执行计划可以定位慢查询的瓶颈所在。
一个典型的慢查询分析过程：查询30天聚合结果耗时45秒。EXPLAIN输出显示扫描了30天×10万测点=25.9亿条原始数据做实时聚合。优化方案：配置1小时级连续查询，查询改为读取连续查询结果表，扫描量降到720×10万=720万条，查询时间降到2秒。再进一步用INTERVAL(1h)降采样，扫描量再降到720条，查询时间降到200毫秒。
慢查询日志是系统级优化手段。TDengine的慢查询日志记录执行时间超过阈值的查询SQL和执行计划，定期分析慢查询日志可以发现系统性的查询性能问题——某个报表查询慢可能是缺少连续查询，某个看板查询慢可能是标签索引缺失。
结语
时序查询优化的逻辑链条清晰：理解查询模式→定位性能瓶颈→选择匹配的优化策略。最新值查询靠缓存，时间范围查询靠分区裁剪，聚合查询靠连续查询预计算，大范围查询靠降采样。四种优化手段各有适用场景，组合使用效果最佳。TDengine提供标签索引+时间分区+连续查询+最新值缓存四重优化机制，覆盖了时序查询的主要性能瓶颈点。查询优化的最终目标不是让某条查询快一倍，而是让系统在高频查询负载下持续稳定响应——这需要从数据建模阶段就开始考虑查询模式，而非等系统上线后再被动优化。
