任务表必须包含状态字段和时间戳字段
任务管理系统最核心的是能区分「待办」「进行中」「已完成」，所以
tasks表里至少要有
status（建议用 ENUM 或 TINYINT）和
created_at/
updated_at。别用
DATETIME默认值
NOW()做更新时间——MySQL 5.6+ 才支持
ON UPDATE CURRENT_TIMESTAMP对
DATETIME生效，老版本会静默失效，直接用
TIMESTAMP更稳妥。
status推荐用
TINYINT：0=待办，1=进行中，2=已完成；比字符串节省空间，也避免大小写/空格导致的查询不一致
updated_at必须设为
TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP如果任务可能被多人协作，加一个
assignee_id（关联用户表），但别在任务表里冗余用户名——那是 JOIN 时的事
用户表和任务表之间用外键还是应用层维护
MySQL 支持外键，但简易系统里不强制启用。如果你用的是云数据库（如阿里云 RDS、腾讯云 CDB），默认可能禁用外键或不支持级联操作；就算开启，
ON DELETE CASCADE在误删用户时反而危险。更实际的做法是：建索引 + 应用层校验。 在
tasks.assignee_id上建普通索引：
CREATE INDEX idx_tasks_assignee ON tasks(assignee_id);插入任务前，SELECT 检查
users.id是否存在；删除用户前，先查
SELECT COUNT(*) FROM tasks WHERE assignee_id = ?外键虽能防止脏数据，但会让迁移、备份、分表更麻烦——简易系统优先保灵活
任务描述字段选 TEXT 还是 VARCHAR(2000)
描述内容不可预估长度，
VARCHAR(2000)看似够用，但用户粘贴带格式的文本、URL、代码片段后很容易超限，报错
Data too long for column。直接上
TEXT更省心，且现代 MySQL（8.0+）对
TEXT的性能优化已足够好。
TEXT不影响 WHERE 查询效率，只要不用
LIKE '%xxx%'全模糊匹配 如果后续要全文检索，再加
FULLTEXT索引：
ALTER TABLE tasks ADD FULLTEXT(description);别用
MEDIUMTEXT或
LONGTEXT——没意义，还可能触发某些 ORM 的类型映射异常
是否需要单独建优先级或标签表
简易系统里，优先级（高/中/低）和标签（如 #bug #feature）都建议用「枚举型字段 + 应用层解析」，而不是建关联表。否则光一个标签功能就要搭
task_tags、
tags两张表+中间表，复杂度翻倍。 优先级：加
priority TINYINT DEFAULT 1（1=低，2=中，3=高），查询时
ORDER BY priority DESC标签：加
tags JSON DEFAULT NULL（MySQL 5.7+），存成
["bug", "backend"]；应用层做增删查，避免多对多关联 如果真要按标签筛选，用
JSON_CONTAINS(tags, '"bug"')，比 JOIN 多张表快得多 实际运行中，最容易被忽略的是时间字段的类型选择和 JSON 字段的索引缺失——比如对
tags做高频查询却不加生成列索引，会导致全表扫描。先跑通逻辑，再根据慢查询日志加索引，比一开始就堆设计更靠谱。
