何时用 Mongo vs SQL

这一课你将能做到

1. 对照场景矩阵，说出至少 3 类「更偏 MySQL」与 3 类「更偏 MongoDB」的具体理由
2. 用本站架构解释：为何 cf_track 留在 MySQL，而做题日志 / 评论适合进 MongoDB
3. 在团队评审中给出「混合持久化」建议，并明确双写风险与单一权威源原则

为什么要学

工具课容易学成「都会一点」；工程上真正值钱的是选型能辩护。面试官问「你们为什么用 MongoDB」时，背得出 CRUD API 没用，答得出「数据形状 + 一致性 + 团队资产」三层理由才有用。

本站的技术决策摆在这里：权威数据（课程、用户、做题进度、订单）在 MySQL——schema.sql、JPA 实体、迁移脚本都是已投入的资产；MongoDB 承接文档型扩展集合。本课把这背后的判断逻辑系统化，让你能在自己的项目里做出并捍卫同类决策。

人话：不是谁更高级，而是「数据长什么样、怎么变、怎么查、一致性要多强」决定谁更合适；外加团队与运维的真实成本。

先建立图像

按职责分层选型：

核心业务 OLTP（用户、课程目录、做题进度、订单）
        → MySQL：事务、JOIN、约束、成熟生态

文档 / 日志 / 多变结构（做题日志、评论、审计、配置树）
        → MongoDB：内嵌、灵活字段、追加写、聚合统计

热点加速 / 会话 / 限流
        → Redis：内存读写，挡在数据库前面

（Nginx 统一入口 → Spring Boot 编排三者）

场景	更常见选择	理由
结构化 OLTP、多表 JOIN	MySQL	SQL 成熟、约束完备、团队熟悉
灵活 schema、嵌套 JSON	MongoDB	免 ALTER、数组内嵌自然
复杂报表、窗口函数	MySQL / PG	分析 SQL 生态强
高写入日志、行为流水	MongoDB	追加友好、TTL 过期、聚合内置
强一致金融账本	MySQL	ACID 与对账习惯成熟
单对象整读（带子结构）	MongoDB	一次读齐，免多次 JOIN

跟着做

步骤 1：写出本站「权威路径」一句话

打开笔记写：「Nginx → Spring Boot → MySQL（cf_track 等）为权威主路径；MongoDB 不替换 spring.datasource，只承接扩展集合。」对照仓库 application.yml，确认数据源主配置仍是 MySQL。

步骤 2：为「课时评论」做双方案草稿

MySQL 版（纸上画表）：

cf_comment(id, track_slug, user_id, body, created_at, ...)
加 @ 提及还要 mention 关联表
展示作者昵称要 JOIN 用户表或冗余快照列

Mongo 版（直接能跑）：

db.comments.insertOne({
  trackSlug: "mongodb-essentials",
  body: "聚合管道讲得很清楚",
  author: { userId: "u_1002", displayName: "学习者A" },  // 快照
  mentions: ["u_1001"],
  createdAt: ISODate("2026-03-02T08:00:00Z")
})

对比结论写进笔记：Mongo 把作者快照与提及数组收进同一文档，读接口一次拿齐；MySQL 版赢在跨评论复杂 JOIN 报表与严格约束。

步骤 3：为「支付订单」做反向练习