这一章必须讲透，否则系统设计很容易走偏。
可以直接先看结论：
| 系统 | 在软件城市里的角色 | 最强项 |
|---|---|---|
| MySQL | 户籍总账楼 | 强事务、约束、关系、精确一致性 |
| MongoDB | 弹性档案仓 | 文档模型灵活、开发形状自然 |
| Elasticsearch | 全城检索雷达中心 | 全文检索、相关性排序、分面聚合 |
很多系统里，这三者不是“谁替代谁”，而是：
写入主链路
App
│
├── 主事实存储 -> MySQL / MongoDB
│
└── 异步同步 -> Elasticsearch
读取链路
用户搜索 -> Elasticsearch
用户点进详情 / 下单 / 核账 -> MySQL / MongoDB这是一条非常常见而且稳定的工程分工线。
为什么？
因为它们解决的问题根本不同。
MySQL 更擅长：
- 订单、支付、库存扣减
- 事务一致性
- 关系约束
- 精确查询与更新
MongoDB 更擅长：
- 结构灵活的业务文档
- JSON 形态天然的数据模型
- 快速迭代文档结构
Elasticsearch 更擅长：
- 标题、正文、评论、日志、商品说明等全文搜索
- 多字段相关性排序
- 搜索结果上的 faceting / aggregations
- 搜索体验优化
如果你的需求只是：
- 按 ID 查
- 按状态查
- 按时间范围查
- 按几个字段做精确过滤
那很多时候 MySQL 或 MongoDB 已经够了，不需要为了“看起来高级”强上 Elasticsearch。
但如果你的需求变成：
- 用户输一句自然语言式线索
- 需要按相关性排前后
- 要支持标题/摘要/正文多字段搜索
- 要同时给品牌、分类、价格区间统计
- 要做搜索页体验，而不是条件筛选页
这时 Elasticsearch 就非常像“正解”。
一句话记住边界：
MySQL / MongoDB 更像事实存储，Elasticsearch 更像面向搜索的派生索引与分析中枢。