【TDengine 使用环境】
生产环境 /
【TDengine 版本】
3.4.1.6
【操作系统以及版本】
red hat enterprise linux server 7.9
【部署方式】容器/非容器部署
非容器部署
【集群节点数】
3
【集群副本数】
3
【描述业务影响】
服务执行查询超时导致报错
【问题复现路径/shan】做过哪些操作出现的问题
将生产集群从3.0.3.0升级到3.4.1.6，执行查询
【遇到的问题：问题现象及影响】
【资源配置】
生产虚拟机三节点集群，各节点32C 64G 数据磁盘3T
【报错完整截图】（不要大段的粘贴报错代码，论坛直接看报错代码不直观）
生产环境该超级表子表数量约40w，总体数据量约130w，执行该查询耗时却超过70s，观察发现其主要耗时在Table Scan处，想请td技术人员帮忙分析是什么原因导致查询如此耗时？（图二为数据库配置）
1、group by 中为什么要 ts： 这个目的是什么？
2、业务上是需要40w子表要全部扫描吗？
group by用ts是因为查询入参可能会包含多个时间戳，只是这次超长查询时间的sql只查询计算26年的数据。
业务上确实是需要对所有子表数据做聚合的。
测试环境基本相同的数据量查询耗时只有几百毫秒，执行计划中的数据块耗时很短。（测试环境集群做过重装和数据补偿）想请教下是否和block太小太多有关？
是的，应该是 涉及到的数据block，每个块中数据量少，导致要访问扫描太多块了。
可以使用这个命令查询一下block的情况:
SHOW TABLE DISTRIBUTED [db_name.]station_statistics_year;
好的，那请教下，修改数据库的minrows参数会改善这种情况吗，存量和新增的都能改善吗？
不一定。修改这个参数会出现数据长时间在 stt 文件中（因为没有达到minrows，就会先临时保存到stt中，等待后续数据过来合并），会负面影响写入和查询。
最好的方法是对数据进行一次 compact 操作，会合并block块中数据，大大减少block数量，达到测试环境中的情况。但compact 这个操作只有 企业版才能支持。
