关系复杂的数据场景更适合传统数据库
公司内部的财务系统，涉及报销、审批、账目核对等多个环节。每个报销单要关联多个审批人，还要对应不同的预算科目和付款记录。这种情况下，数据之间的关系错综复杂，用 NoSQL 存储会变得特别别扭。比如 MongoDB 这类文档数据库，虽然能存嵌套结构，但一旦需要跨文档做一致性查询或级联更新，写起来费劲，维护更头疼。反而是 MySQL 这样的关系型数据库，用 JOIN 轻松搞定多表关联，事务也能保证数据一致。
强一致性要求高的业务别轻易上 NoSQL
银行转账是个典型例子。用户从账户 A 转 500 元到账户 B，必须确保 A 扣钱和 B 加钱同时成功或失败。NoSQL 多数采用最终一致性模型，像 Cassandra 或 DynamoDB，在网络分区时可能暂时出现数据不一致。这时候如果查到账户余额少了但对方没收到，客户肯定炸锅。而传统数据库支持 ACID 事务，一条 UPDATE 语句就能锁住两行记录，操作原子性有保障，不怕中间出岔子。
需要复杂查询的报表系统慎用 NoSQL
运营部门每周要出一份用户活跃度分析报告，按地区、年龄段、设备类型、使用时长多维度交叉统计。这类需求往往得写一堆 GROUP BY 和子查询。NoSQL 查询能力普遍较弱，MongoDB 的聚合管道写起来啰嗦，性能也不如优化过的 SQL。再加上索引策略不如 MySQL 灵活，面对动态筛选条件容易翻车。不如老老实实用关系库加视图，或者专门上 OLAP 方案。
已有成熟 SQL 技能团队时没必要强行切换
小李公司原来用 PostgreSQL 做订单管理，DBA 对索引优化、执行计划调优门儿清。去年技术会上有人提议换成 Redis + Elasticsearch 组合提升性能，结果迁移半年没跑通历史数据归档流程，半夜报警频发。最后发现还是原来的外键约束和物化视图更省心。工具是为人服务的，团队熟悉 SQL，现有系统跑得稳，就没必要为了“时髦”去折腾 NoSQL。
数据规模根本没达到瓶颈
一个社区网站，用户量几万，每天新增几百条帖子。这种体量，MySQL 单机都能扛住。非要上 MongoDB 分片集群，不仅硬件成本翻倍，运维复杂度也上去了。就像家里吃饭，本来四口人一张圆桌就够了，非得摆个能坐五十人的大宴席台面，既浪费空间又难收拾。数据量没上来时，NoSQL 的横向扩展优势根本体现不出来，反而把简单问题搞复杂了。