Apache Ignite两种缓存创建方式差异及对Calcite优化器超时的影响

一、两种缓存创建方式的实质性差异 #

底层键值存储一致性 #

默认情况下，SQL DDL（CREATE TABLE）和编程式CacheConfiguration创建的缓存，底层键值存储结构是完全一致的。因为SQL DDL最终会被Ignite解析为对应的CacheConfiguration实例，并自动生成匹配的QueryEntity来映射表结构到键值对。

核心功能差异 #

• 高级存储特性支持：编程式配置可以直接通过CacheJdbcPojoStoreFactory绑定RDBMS实现读写穿透/写通缓存，而SQL DDL没有原生语法支持该特性——如果需要给DDL创建的表添加这类存储配置，只能在创建后通过Ignite API修改缓存的CacheConfiguration。
• 配置灵活性：编程式方式支持启动阶段完成所有复杂配置（自定义序列化器、分区策略、缓存组、事务属性等）；SQL DDL更适合运行时动态创建表结构，但后续补充高级配置需要依赖API操作。
• 元数据可见性：SQL DDL创建的表会自动注册到Ignite系统元数据缓存中，可直接通过SHOW TABLES等SQL命令查看；编程式创建的缓存如果未配置QueryEntity，则不会出现在SQL元数据中，仅作为纯键值缓存存在。

二、Calcite优化器超时问题分析 #

缓存创建方式不会直接导致Calcite优化器行为差异——只要两种方式生成的QueryEntity、索引（QueryIndex）、分区规则等核心查询元数据完全一致，优化器的计划生成逻辑是相同的。超时问题更可能来自以下因素：

• 查询复杂度过高：多表深度关联、多层嵌套子查询、大量笛卡尔积场景会让Calcite在规则匹配和代价计算阶段耗时剧增。
• 索引配置不合理：缺少必要的联合索引或覆盖索引，导致优化器需要枚举更多执行路径才能找到最优计划。
• 统计信息缺失/过时：Ignite依赖表的统计数据（比如行数量、字段基数）来估算执行代价，如果统计信息未收集或长时间未更新，Calcite可能会陷入低效的计划探索，甚至超时。
• 优化器参数配置：可检查Ignite配置中的sql.optimizer.timeout参数（默认30秒），根据场景调整超时阈值；也可以禁用部分代价较高的优化规则（比如sql.optimizer.disabled_rules）来缩短计划生成时间。

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