未开启持久化的Ignite执行分组统计SQL触发30秒超时问题咨询

超时根因分析 #

• 全表扫描开销过大：从运行日志可见，该问题SQL单次扫描行数最高可达14万+，同过滤条件的其他查询扫描行数甚至超过45万，说明查询未命中有效索引，所有过滤条件需要逐行匹配判断，数据量较大时扫描耗时会陡增。
• 分组逻辑冗余低效：SQL中GROUP BY直接拼接三个字段的字符串，每次分组都需要先执行CONCAT计算，字符串拼接+哈希分组的开销远高于直接按原始字段分组，额外消耗大量CPU资源。同时WHERE子句存在重复判断逻辑：specialAlarmStatus =0和specialAlarmStatus in (0)功能完全重复，也会增加不必要的计算开销。
• 分布式聚合传输/计算开销高：该SQL执行阶段为REDUCE，需要先从所有节点拉取符合条件的中间数据，再在协调节点做二次聚合、全局排序，数据量较大时网络传输和内存计算压力会被放大。当前查询未开启lazy模式，所有数据一次性加载到内存处理，进一步加重了资源负担。

优化解决办法 #

1. 新增联合索引避免全表扫描 #

创建覆盖过滤条件+分组字段的联合索引，让查询可以直接通过索引获取所有需要的字段，无需回表访问原始数据：

CREATE INDEX idx_alarm_filter_group ON T_CURRENT_ALARM (specialAlarmStatus, invalidated, merged, changeFlag, meName, nativeMeDn, originSystemId);

2. 优化SQL逻辑减少冗余计算 #

删除重复判断条件，调整分组逻辑，将字符串拼接从分组阶段后置到最终查询输出阶段，降低计算开销，优化后SQL参考：

SELECT CONCAT(MENAME,'<==>', NATIVEMEDN,'<==>', ORIGINSYSTEMID), COUNT(1)  
FROM T_CURRENT_ALARM  
WHERE specialAlarmStatus =0 
  AND invalidated =0 
  AND merged in (0,1) 
  AND (changeFlag !=3 OR changeFlag is null)  
GROUP BY meName, nativeMeDn, originSystemId 
ORDER BY count(1) DESC 
LIMIT 10

3. 调整查询参数适配分布式场景 #

执行SQL时开启lazy模式，让数据分批加载处理，避免一次性加载大量数据导致内存占用过高、处理卡顿，JDBC连接参数示例：

jdbc:ignite:thin://<your_ignite_address>/;lazy=true

如果三个分组字段的关联数据满足同节点存储的条件，可额外开启collocated=true参数，减少跨节点的数据传输开销。

4. 兜底调整超时阈值 #

如果存在偶发的大数据量查询场景，可临时调整SQL超时阈值，避免直接报错：

-- 调整当前会话超时时间为60秒
ALTER SESSION SET QUERY_TIMEOUT = 60000;

内容的提问来源于stack exchange，提问作者biandeqiang