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舌诊面诊问诊医疗系统+诊疗商城系统源码

AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。

下载

• 在任务开始前就预写一条 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)

基本上就这些。表结构不复杂，但字段语义和写入节奏容易忽略，一旦出错，排查成本会指数上升。