数据库
设计博客系统表结构
设计用户、文章、分类、标签、文章标签关联表，明确字段、主键、外键和索引。
产出物一份建表 SQL 或 Prisma schema。
Checklist
阶段任务
- 理解数据库、表、字段、行、主键、外键
- 掌握 varchar、text、int、bigint、decimal、datetime、boolean 等常见字段类型
- 掌握 SELECT、INSERT、UPDATE、DELETE
- 掌握 WHERE、ORDER BY、LIMIT、JOIN
- 理解索引的作用和常见使用场景
- 理解数据库迁移 migration
- 理解唯一约束、非空约束、默认值和软删除字段
- 理解事务、并发更新、乐观锁和数据一致性
- 理解 N+1 查询、慢查询和基础 EXPLAIN 思路
- 用 ORM 改写简单 SQL 查询
- 了解 Redis 缓存适合解决什么问题，以及缓存失效风险
Labs
建议练习
SQL
写常见查询
写出文章分页、按分类筛选、按关键词搜索、查询用户文章列表的 SQL。
产出物至少 5 条可运行 SQL。
数据库
事务练习
设计发布文章时同时写入文章表和标签关联表的流程，要求使用事务并说明失败时如何回滚。
产出物一段事务伪代码或 ORM 代码。
SQL
索引 Review
让 AI 检查博客表结构是否缺少索引，尤其关注分页、筛选、详情和唯一字段。
产出物一份索引建议和每个索引解决的查询问题。
Daily Plan
每日安排
Day 1
表结构和字段类型
把业务对象拆成表、字段、主键、外键和约束。
- 设计 users、posts、categories、tags、post_tags 表
- 为每个字段选择类型、是否必填、默认值
- 标记主键、外键、唯一约束和 created_at、updated_at
- 说明哪些数据适合软删除
当天产出一份博客系统表结构草案。
Day 2
SQL 查询和分页
用 SQL 真正查出前端页面需要的数据。
- 写文章列表分页 SQL
- 写按分类、标签、关键词筛选的 SQL
- 写文章详情及作者信息的 JOIN 查询
- 用 LIMIT/OFFSET 理解分页成本
当天产出至少 6 条可运行 SQL。
Day 3
索引和查询性能
知道为什么列表接口越用越慢，以及哪些字段应该建索引。
- 为 user_id、category_id、status、created_at、slug 设计索引
- 理解联合索引的字段顺序
- 用 EXPLAIN 观察一条查询是否使用索引
- 记录哪些搜索场景不适合普通 LIKE
当天产出一份索引设计说明和慢查询排查笔记。
Day 4
事务、一致性和 ORM
理解一次业务操作可能同时改多张表，不能只看单条 SQL。
- 设计发布文章时同时写 posts 和 post_tags 的流程
- 用事务保证多表写入要么都成功要么都失败
- 用 Prisma、SQLAlchemy 或 MyBatis 改写同一段逻辑
- 让 AI 检查是否存在 N+1 查询和事务遗漏
当天产出一段带事务的业务写入示例。
Day 5
缓存和数据变更
知道 Redis 缓存能提升读性能，也会带来过期、失效和一致性问题。
- 理解缓存命中、缓存穿透、缓存过期的基本概念
- 为文章详情或热门文章设计一个简单缓存策略
- 思考文章更新后缓存如何失效
- 记录哪些数据不适合缓存或必须谨慎缓存
当天产出一份文章接口缓存策略草案。
Knowledge
知识点解释
数据库设计决定了后端能否稳定扩展。AI 能写 SQL，但你需要知道表关系和查询是否符合业务。
主键
每一行数据的唯一标识，通常是 id。
前端类比：类似列表渲染里的 key，但数据库主键更严格。
外键
表示两张表之间的关联关系，比如文章属于某个用户。
前端类比：类似前端状态里 article.userId 指向 users 里的某个用户。
索引
提升查询速度的数据结构，常用于 id、外键、搜索条件和排序字段。
前端类比：类似给大数组提前建立查找表，避免每次全量遍历。
ORM
把数据库表映射成代码对象，减少重复 SQL。
前端类比：类似用类型化 SDK 调接口，而不是每次手写 fetch。
事务
把多次数据库操作包成一个整体，要么全部成功，要么全部失败，避免数据写一半。
前端类比：类似一个多步骤提交，要保证最终状态不能停在半成品。
软删除
不真正删除数据库记录，而是用 deleted_at 或 status 标记删除，便于恢复和审计。
前端类比：类似前端列表隐藏已删除项，但数据仍保留在后台。
Redis 缓存
把高频读取的数据临时放到内存服务里，减少数据库压力。
前端类比：类似前端缓存接口响应，但后端缓存要考虑多用户和数据一致性。
N+1 查询
先查一批数据，再为每一条单独查关联数据，导致请求数随列表长度暴涨。
前端类比：类似页面渲染 20 条数据却发了 21 个接口请求。
常见坑点
- 不要只会 ORM 而完全不懂 SQL
- 金额不要随便用浮点数
- 删除数据前要考虑软删除和关联数据
- AI 生成表结构后，要检查字段是否满足真实业务查询
- 不要给所有字段盲目加索引，写入成本和存储成本也会增加
- 多表写入没有事务，失败时很容易留下半成品数据
- 缓存不是万能优化，更新数据时必须考虑缓存失效
Prompts
AI 协作提示词
设计数据库
请帮我为一个博客系统设计数据库表。功能包含用户、文章、分类、标签、文章标签关联。请输出表结构、字段说明、主键和外键、常用查询 SQL。请额外说明前端调用文章列表接口时，后端如何查询数据库。检查表结构
请 Review 下面的数据库表结构。请重点检查字段类型是否合理、是否缺少索引、表关系是否正确、分页查询是否高效、是否有数据一致性风险。检查 SQL 和 ORM 查询
请 Review 下面的 SQL 或 ORM 查询。请重点检查是否会全表扫描、是否有 N+1 查询、分页是否稳定、索引是否能命中、事务是否完整、并发更新是否可能造成数据覆盖。请给出优化建议和必要的表结构调整。Acceptance
验收标准
- 能看懂基本建表语句
- 能写简单 SELECT 和 JOIN
- 能解释 ORM 和 SQL 的关系
- 能为常见查询设计基础索引
- 能解释事务、软删除和缓存失效
- 能让 AI 生成表结构后再做人工检查
Resources
推荐资源
Progress