SQL任务流水表结构说明_SQL记录状态变化过程

SQL任务流水表是记录任务状态变更全过程的日志式表，核心字段包括task_id、status_before/after、operator、trigger_time、reason和trace_id，需严格按真实状态跃迁写入并保证事务一致性。

SQL任务流水表用于记录任务从创建到完成（或失败）全过程中的每一次状态变更，核心目标是可追溯、可审计、可排查。它不是只存最终结果的快照表，而是按时间顺序沉淀每一次“状态跃迁”的日志式结构。

核心字段设计（必含）

一个健壮的任务流水表至少包含以下字段：

• task_id：任务唯一标识，通常与主任务表外键关联
• status_before 和 status_after：变更前/后状态码（如 'INIT' → 'RUNNING' → 'SUCCESS'），便于还原跳变路径
• operator：触发变更的操作方（如 'scheduler'、'api_user_123'、'retry_worker'），区分自动与人工干预
• trigger_time：状态变更发生的时间戳（建议用 UTC 存储，避免时区混淆）
• reason：简要说明变更原因（如 'timeout_reached'、'manual_retry'、'dependency_met'），非空推荐，尤其对异常流转
• trace_id（可选但强烈推荐）：关联分布式链路ID，方便跨服务追踪上下文

状态值定义需收敛且语义明确

避免使用模糊值（如 'processing'、'doing'），统一采用大写短码，例如：

• INIT：任务已生成，未调度
• QUEUED：已入队，等待执行资源
• RUNNING：正在执行中
• SUCCESS / FAILED / TIMEOUT / CANCELLED：终态，不可再变
• RETRYING：因失败触发重试，属于中间态（注意：不是所有失败都进此态，需策略控制）

所有状态码应在代码中定义为常量，并在文档中维护状态迁移图（如不允许从 FAILED 直接跳到 SUCCESS）。

写入时机必须严格对应真实状态跃迁

不是“每执行一步就写一条”，而是“每次状态字段实际更新时才写入”。常见错误包括：

标签： ai 状态码