NoSQL不是万能的，这些情况最好别用
说到数据库，很多人第一反应就是MySQL、PostgreSQL这类关系型数据库。但近几年NoSQL也火得不行，MongoDB、Redis、Cassandra动不动就被拿来当首选。可问题是，NoSQL真适合所有项目吗？其实不是，有些场景硬上NoSQL，反而会让系统变得更慢、更难维护。
需要强事务支持的业务
比如你做个银行转账功能，A账户扣100，B账户加100，这必须同时成功或同时失败。这种强一致性操作，传统数据库用BEGIN TRANSACTION就能搞定。但多数NoSQL不支持多行事务，或者只在有限范围内支持。MongoDB虽然4.0后支持了多文档事务，但性能损耗明显，高并发下容易成瓶颈。
再举个例子，电商平台的订单创建，涉及库存扣减、订单生成、优惠券核销等多个步骤。如果用Redis或Cassandra这类最终一致性的数据库，中间出点问题，用户钱扣了但订单没生成，客服就得忙到半夜。
数据关系复杂，频繁关联查询
如果你的系统经常要查“用户买了什么商品，商品属于哪个分类，卖家是谁，有没有售后”，这种多表JOIN操作，关系型数据库一条SQL就能搞定。而NoSQL通常把数据打散存，查一次得发多个请求，代码写得又长又容易出错。
比如用MongoDB存用户和订单，想查某个分类下所有用户的消费总额，就得先查商品列表，再遍历用户，再聚合订单。不如MySQL一句LEFT JOIN GROUP BY来得干脆。
SELECT u.name, SUM(o.amount) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id;需要严格的数据结构和约束
NoSQL主打灵活schema，字段可以随时增减。听起来方便，但在团队协作的大项目里，没人管字段定义，时间一长数据格式五花八门。今天存个price是数字，明天来个字符串"free"，程序一解析直接报错。
财务系统、报表系统这类对数据准确性要求高的地方，还是用MySQL这种有明确字段类型、非空约束、外键检查的更稳妥。不然月底对账发现数据对不上，排查起来够喝一壶。
已有成熟的关系型架构
有些公司业务本来跑得好好的，用着Oracle+MyBatis，结果为了“技术升级”强行换成MongoDB。结果发现连接池不好配，监控工具不兼容，SQL审计全失效，运维一脸懵。特别是涉及大量历史数据迁移，风险高、耗时长，改完还没性能提升。
就像你家电视能看，非换成最新款8K的，结果网络带宽跟不上，视频老是卡。技术选型不是赶时髦，得看实际需求。
小项目或初创阶段乱用
很多创业团队一开始数据量不大，用户才几千，上来就搞Cassandra集群、Redis分片，配置一堆参数，最后发现连基本的备份都没做。出了问题恢复不了，数据全丢。
其实这时候用个SQLite或者单机MySQL，简单备份定时dump一下就行。NoSQL的优势在海量数据和高并发，小项目用，纯属杀鸡用牛刀，还把自己累够呛。
技术没有高低，只有合不合适。NoSQL在日志存储、会话缓存、实时推荐这些场景确实猛，但该用关系型的时候，别硬撑。选对工具，比追新更重要。