数据关系复杂时，别硬上NoSQL
很多公司一开始做项目，听说NoSQL快、灵活，就一股脑地往MongoDB、Redis里塞数据。可真到了业务复杂起来，比如用户权限、订单关联、财务流水这些需要多表连接的场景，NoSQL就开始露怯了。关系型数据库的JOIN操作在这些地方几乎是刚需，而NoSQL基本靠应用层拼数据，代码越写越乱，查个问题得翻三四个集合。
比如你做个后台系统，要查某个用户的全部订单及对应的商品信息，MySQL一条JOIN搞定的事，在MongoDB里可能得先查用户，再拿ID遍历订单，再逐个查商品。网络延迟加上多次查询，响应时间直接翻倍。
事务要求高的场景别碰NoSQL
银行转账、库存扣减这种操作，要么全成功，要么全回滚，容不得半点差错。MySQL、PostgreSQL这类数据库支持ACID事务，能保证数据一致性。而多数NoSQL只提供单文档事务，跨文档或多行操作基本没法保证原子性。
举个例子：电商大促时，用户下单要同时扣库存、生成订单、冻结金额。用MongoDB虽然可以搞多文档事务，但性能损耗明显，还容易锁住资源。这时候不如老老实实用MySQL，稳定又省心。
需要强一致性的系统慎用NoSQL
NoSQL很多基于分布式架构，为了追求高可用和分区容忍性，往往牺牲强一致性（CAP理论里的C）。像Cassandra、DynamoDB这类数据库，默认是最终一致性，意味着你刚写入的数据，可能在另一个节点查不到。
想象一下，用户充值后刷新页面，余额却没到账，客服电话立马被打爆。这种体验在金融类或管理后台系统里是致命的。这时候就得用MySQL这类强一致的数据库，写入即可见，避免用户疑虑。
已有成熟SQL生态的团队没必要折腾
有些公司技术栈一直用Java + Spring + MySQL，DBA熟悉索引优化、慢查询分析，报表系统也都是基于SQL写的。突然换NoSQL，不仅学习成本高，连监控、备份、迁移工具都得重配一套。结果发现开发效率不升反降，出问题还没人能快速定位。
更别说很多BI工具、数据分析平台，原生支持的是JDBC连接，对NoSQL支持有限。临时导个数据都得写脚本中转，费时费力。
数据量根本不大时，用NoSQL纯属浪费
见过最夸张的例子是，一个内部小工具，用户才几百，数据不过万条，非要上MongoDB集群。理由是‘以后可能会扩展’。结果运维成本上去了，查询也没快多少。
其实这种场景，SQLite或者单机MySQL足矣。NoSQL的优势在海量数据和高并发读写，小项目压根用不上。就像搬家非得雇辆卡车，搬完才发现就几本书。
有合规和审计要求的系统要小心
金融、医疗这类行业，对数据完整性、操作日志、访问控制都有严格规定。MySQL可以通过触发器、binlog、审计插件实现完整追踪。而多数NoSQL在这方面支持较弱，有的甚至连细粒度权限控制都没有。
比如你要记录谁在什么时候修改了某条患者信息，MySQL配合binlog解析就能实现。MongoDB虽然也有oplog，但配置复杂，且默认不开启详细审计。一旦被检查，合规风险立马浮现。
说到底，NoSQL不是万能药。它适合日志存储、缓存、用户行为采集这类松散结构、高吞吐的场景。但涉及核心业务、强一致性、复杂查询的地方，传统关系型数据库依然更靠谱。技术选型不该追潮流，而要看实际需求。