说到数据库，很多人一听“高性能”“高并发”就想到NoSQL，比如MongoDB、Redis、Cassandra。确实，NoSQL在处理海量数据和灵活结构方面有优势，但并不是所有场景都适合。
数据关系复杂时别硬上NoSQL
如果你的系统需要频繁做多表关联，比如电商里的订单、用户、商品、地址之间来回查询，用关系型数据库更自然。SQL一句JOIN就能搞定的事，换成MongoDB可能得发好几条查询，还得自己在代码里拼数据。不仅麻烦，还容易出错。
举个例子，你想查“某个用户最近三个月买过哪些商品，每单花了多少钱”，MySQL里一条带JOIN的SELECT就能出结果。但在文档数据库里，你可能得先查订单，再逐个查商品信息，逻辑全堆在应用层，后期改起来头疼。
需要强事务保证的场景
银行转账、库存扣减这类操作，必须保证“要么全成功，要么全失败”。传统关系库支持ACID事务，跨表甚至跨库都能回滚。而大多数NoSQL对事务支持有限，即便现在有些也支持了，复杂度和性能代价也不低。
比如你写个秒杀系统，发现库存减了，但订单没生成，钱却扣了——这种问题在弱事务支持的NoSQL里更容易发生。这时候不如老老实实用MySQL或PostgreSQL。
数据结构长期稳定
NoSQL的优势之一是 schema free，适合字段经常变的场景。但如果你的数据结构早就定死了，比如用户表就那十几个字段，几年都不动，那用NoSQL就有点杀鸡用牛刀。
相反，关系型数据库的约束机制（比如外键、唯一索引、非空校验）反而能帮你避免很多低级错误。比如防止插入一个不存在的用户ID，或者让手机号格式乱填。
团队不熟悉运维成本高
别忽视人的因素。如果你团队里没人真正用过MongoDB分片集群，突然在线上搞一套，出问题了查半天日志都不知道哪儿错了。而MySQL大家多少都接触过，备份、监控、调优工具一抓一大把。
技术选型不是比谁新潮，而是看谁能更快交付、更少出事。一个小团队做个后台管理系统，非要上Cassandra，最后花两周配环境，不如用SQLite跑得还快。
已有成熟SQL生态
公司内部已经有报表系统、BI工具、审计平台，全都基于SQL查询。你换一套NoSQL，这些工具全用不了，还得额外开发接口。时间一长，业务部门抱怨数据拿不到，技术债越堆越多。
有时候，不是技术不行，而是生态没跟上。与其推倒重来，不如在原有体系里优化。
技术没有银弹。NoSQL是好东西，但不代表它适合所有情况。该用MySQL的时候，别怕被人说“老派”。能解决问题，才是最关键的。