从谁的角度看
| 对比维度 | MySQL 强一致、事务、复杂查询 | MongoDB 灵活 schema、嵌套文档 |
|---|---|---|
| 数据模型 | ||
| 存储单位 | 表 / 行 / 列 | 集合 / 文档（BSON） |
| Schema | 严格，改表要 DDL | 灵活，字段可随时增减 |
| 关联查询 | 多表 JOIN，成熟高效 | $lookup 能力有限，建议内嵌 |
| 功能特性 | ||
| 事务 | 完整 ACID，成熟 | 4.0+ 支持多文档事务，性能有损耗 |
| 索引 | B+ 树，二级索引需回表 | B 树 + 多键/文本/地理索引 |
| 扩展方式 | 垂直为主，分库分表要自己做 | 原生分片，按分片键水平扩展 |
| 运维与生态 | ||
| 一致性 | 强一致（主从异步有延迟） | 可调读写关注，默认最终一致 |
| 典型场景 | 订单、账务、权限、报表 | 商品详情、内容、日志、画像 |
点某一行可以高亮该维度，方便逐条横向读；移动端左右滑动查看全部列。
选型建议
MySQL
钱、订单、库存这类不能错的数据，老老实实用 MySQL。
MongoDB
结构多变、以单个对象为中心读写、需要水平扩展，用 MongoDB 更顺手。
一句话结论
多数公司是混用：交易数据在 MySQL，商品详情和日志在 MongoDB。别为了「不用改表」把账务数据放进文档库。