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）。
写入时机必须严格对应真实状态跃迁
不是“每执行一步就写一条”，而是“每次状态字段实际更新时才写入”。常见错误包括：
- 在任务开始前就预写一条 status_after=’RUNNING’ —— 实际可能根本没启动
- 重试逻辑里重复写相同状态（如连续两次写 RUNNING）—— 导致流水失真
- 异常捕获后未写 FAILED，仅更新主表 —— 流水断裂，无法定位断点
推荐做法：将流水写入与状态更新放在同一事务中（或通过可靠消息最终一致），确保“状态变，流水到”。
查询典型场景示例
日常运维和问题分析常依赖以下查询：
- 查某任务全生命周期：
select * FROM task_flow WHERE task_id = 't-789' ORDER BY trigger_time - 查超时未结束的任务及最后动作：
SELECT task_id, status_after, operator, reason FROM task_flow WHERE trigger_time > NOW() - INTERVAL '30 minutes' AND status_after IN ('RUNNING', 'RETRYING') GROUP BY task_id, status_after, operator, reason ORDER BY MAX(trigger_time) DESC - 统计各状态停留时长（需自连接或窗口函数）：
SELECT f1.task_id, f1.status_after, EXTRACT(EPOCH FROM (f2.trigger_time - f1.trigger_time)) AS duration_sec FROM task_flow f1 JOIN task_flow f2 ON f1.task_id = f2.task_id AND f2.trigger_time = (SELECT MIN(trigger_time) FROM task_flow f3 WHERE f3.task_id = f1.task_id AND f3.trigger_time > f1.trigger_time)
基本上就这些。表结构不复杂，但字段语义和写入节奏容易忽略，一旦出错，排查成本会指数上升。
