任务状态字段怎么设才不翻车
直接用 ENUM 或字符串存 "pending"/"running"/"success"/"failed" 是常见错误。MySQL 的 ENUM 修改成本高，且 ORM 映射容易出错；纯字符串又没约束，写错一个值（比如 "succeed"）就埋下静默故障。
推荐用 tinyint + 注释方式：定义 status TINYINT NOT NULL DEFAULT 0 COMMENT '0=pending,1=running,2=success,3=failed,4=retrying'。数值比较快、索引效率高，变更也只需改注释和代码常量。
- 避免用
NULL表示初始状态——查起来要加IS NULL，没法走索引 - 状态值必须在应用层硬编码为常量（如 Python 的
TaskStatus.PENDING = 0），别靠数据库注释“凭记忆”写 - 如果需要支持「暂停」「取消」等扩展状态，预留空位（比如跳着编号：0/1/2/3/10/11），别等到上线后才发现要 ALTER COLUMN
重试次数和下次执行时间怎么存才靠谱
很多人把重试逻辑全压在应用层判断，结果调度器一重启，retry_count 就丢了，或者 next_run_at 算错时区变成负数。
关键原则：所有决定重试的依据，必须固化到表里，不能依赖内存或临时变量。
-
retry_count TINYINT UNSIGNED NOT NULL DEFAULT 0—— 超过阈值（如 3）就置为failed，不再更新 -
next_run_at DATETIME(3) NULL—— 用DATETIME(3)存毫秒精度，避免多实例竞争时因秒级精度撞上同一时间点 - 首次插入时，
next_run_at必须设为具体时间（如NOW() + INTERVAL 10 SECOND），不是NULL或默认值 - 不要用
UNIX_TIMESTAMP()存整数——跨时区迁移或夏令时调整时会错乱
如何防止多个 worker 同时抢同一个任务
典型现象：日志里反复看到 "task_id=123 started by worker-A" / "task_id=123 started by worker-B"，说明没锁住。
靠 SELECT ... FOR UPDATE 在事务里查+改，是最稳的。但要注意：它只对已存在的行加锁，对 WHERE 条件不匹配的行无效——所以不能先 SELECT 再 UPDATE，得合并成原子操作。
- 用
UPDATE tasks SET status = 1, worker_id = 'w-abc', updated_at = NOW(3) WHERE id = ? AND status = 0 LIMIT 1，检查ROW_COUNT()是否为 1 - 别用
SELECT ... WHERE status = 0 ORDER BY id LIMIT 1再去更新——并发下两条 SELECT 可能同时命中同一行，后续 UPDATE 都成功 - 如果用乐观锁（
version字段），务必在WHERE里带上AND version = ?，且每次更新都version = version + 1 - 注意隔离级别：
READ COMMITTED足够，REPEATABLE READ可能导致间隙锁阻塞
为什么 status 更新后立刻查不到新值
不是 MySQL 问题，是应用层用了连接池 + 自动提交关了，或者事务没提交就去查。
最常踩的坑：worker A 更新了 status，但没 COMMIT，紧接着用另一个连接（甚至另一个服务实例）去查，自然还是旧值。
- 确认连接是否开启自动提交（
AUTOCOMMIT=1），尤其用 SQLAlchemy 时，默认可能关着 - 别在事务里更新状态后，再发 HTTP 请求调用其他服务——万一对方回调查库，你这边事务还没提交
- 如果必须跨服务协调，用最终一致性方案：更新状态后发 MQ 消息，由消费者去查最新状态，而不是同步轮询
- 调试时用
SELECT * FROM tasks WHERE id = ? LOCK IN SHARE MODE看实时值，比SELECT *更可靠
事情说清了就结束。状态转换的边界、重试的判定条件、并发控制的粒度——这三个地方只要有一个松动，调度表就会从工具变成定时炸弹。
