这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
业务场景
起点
那是 2023 年的一个周末。
我刚完成了一个内容平台的 MVP 版本，核心功能很简单：
- 用户可以发布文章
- 其他用户可以阅读文章
- 每篇文章有标题、内容、发布时间
“看起来不错，” 我的朋友看完后说，“但总觉得少了点什么。”
“少了什么？” 我问。
“点赞啊！” 他说，“没有点赞，作者怎么知道大家喜欢他的文章？用户怎么表达认可？”
那一刻，我意识到：点赞功能不是锦上添花，而是必需品。
需求分析
我坐下来，仔细思考点赞功能到底需要什么：
核心功能
用户视角：
1. 看到文章时，能看到这篇文章有多少人点赞
2. 如果我点过赞，按钮是高亮状态
3. 点击点赞按钮，数字 +1，按钮变高亮
4. 再次点击，取消点赞，数字 -1，按钮变灰
作者视角：
1. 看到自己的文章有多少点赞
2. 点赞数能激励我继续创作
平台视角：
1. 统计热门文章（按点赞数排序）
2. 推荐高赞文章给用户数据需求
文章维度：
- 点赞总数：这篇文章被点赞的次数
- 点赞用户列表：谁点过赞（用于判断当前用户是否点赞）
用户维度：
- 我点赞的文章列表（可选，后续功能）看起来很简单，对吧？
我当时也是这么想的。
第一版设计
我打开数据库设计工具，创建了一张表：
数据设计要点
- 核心是在
article_likes里保存业务事实，而不是把规则散落在应用逻辑里。- 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
- 关键字段包括
id、article_id、user_id、created_at，它们决定后续查询和管理能力。
这个设计满足了我的需求：
- 每条记录代表一个用户对一篇文章的点赞
UNIQUE KEY保证了用户不能重复点赞- 想知道文章的点赞数？
SELECT COUNT(*) FROM article_likes WHERE article_id = ? - 想知道用户是否点赞？
SELECT * FROM article_likes WHERE article_id = ? AND user_id = ?
完美！
我在后台写了个接口：
然后我又写了个获取点赞数的接口：
上线，测试，完美运行！
初步成果
两周后，我看了看数据：
文章数：156 篇
用户数：482 人
点赞总数：2,341 次
日均点赞：约 150 次一切正常，用户很喜欢这个功能。
我还发现了一些有趣的数据：
点赞最多的文章：
1. "如何学习系统设计" - 127 赞
2. "我的创业故事" - 98 赞
3. "技术选型指南" - 76 赚看到这些数字，我感到很满足。用户在互动，作者在创作，平台在成长。
潜在问题
虽然功能正常运行，但我开始思考一些问题：
问题 1：性能
每次获取文章详情，都要执行两个额外查询：
- 查询点赞数：
SELECT COUNT(*) - 查询是否点赞：
SELECT *
如果文章列表页显示 20 篇文章，就是 40 个额外查询！
问题 2：扩展性
现在每天只有 150 次点赞，如果平台增长到：
- 100 倍：15,000 次/天
- 1000 倍：150,000 次/天
数据库扛得住吗？
问题 3：一致性
如果用户快速点击点赞/取消点赞：
- 网络延迟可能导致状态不一致
- 数据库事务可能冲突
这些问题暂时没有暴露，但我知道它们迟早会来。