为何Cadence服务器仅执行任务删除DB查询，工作流超时未调度

以下是可能导致该现象的核心原因：

• 任务清理进程长期阻塞：你看到的delete语句是Cadence内置的任务清理逻辑，用于清理已完成、过期的任务记录。如果该查询因数据量过大、缺少合适索引变成慢查询，会长期占用数据库连接或持有表锁，直接阻塞其他依赖tasks表的关键操作——比如工作流任务的调度入队、待执行任务的读取，最终导致所有工作流无法被调度并超时。

• 数据库资源被耗尽：持续运行的清理查询会抢占数据库的CPU、磁盘IO、连接池等核心资源，导致数据库无法处理正常的工作流调度请求。比如连接池被清理进程占满，或者磁盘IO被大量数据删除操作占满，后续的调度查询因资源不足超时失败。

• 任务清理逻辑异常触发：可能是某个任务列表（task_list_name）堆积了海量过期任务，触发了批量清理但无法在短时间内完成；也可能是Cadence的清理配置不合理（比如单次清理的limit值设置过大、清理频率过高），导致清理进程一直处于运行状态，持续抢占调度所需资源。

• 数据库锁竞争升级：如果数据库（如MySQL）在执行该delete时，因扫描数据范围过大触发表级锁（而非行级锁），会直接阻塞所有对tasks表的读写操作。工作流调度依赖从tasks表读取待执行任务，自然会因锁等待超时。

快速排查方向 #

• 检查tasks表是否存在覆盖domain_id、task_list_name、task_type、task_id的复合索引，缺少索引会导致delete全表扫描，大幅拖慢执行速度。
• 查看数据库锁状态，确认是否有长期持有的锁阻塞了其他tasks表操作。
• 核对Cadence清理相关配置（如history.cleanup.batch.size、history.cleanup.interval），排查是否因配置不当导致清理任务持续运行。
• 查询tasks表中符合该delete条件的数据量，若数据量极大，说明之前的清理机制失效，堆积了大量未及时清理的任务。

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