关系模型在多表JOIN、高频写入、动态Schema等场景下成为瓶颈，需按职责混合使用Redis（缓存）、MongoDB（灵活文档）、PostgreSQL（强事务）等存储。
写不下去的 JOIN 和越来越慢的报表查询
当 SELECT * FROM orders JOIN users ON orders.user_id = users.id JOIN addresses ON users.id = addresses.user_id 开始在生产环境跑出 3s+ 延迟，且加索引、分库分表都收效甚微时，说明关系模型正在成为瓶颈。这不是 SQL 不行，而是数据访问模式已偏离「强关联+多跳查询」的设计初衷。常见信号包括：单次查询需跨 4 张以上表、报表 SQL 中嵌套 3 层子查询、GROUP BY 后再 HAVING 过滤仍超时。这时候硬扛只会让 DBA 和后端一起失眠。
用户行为日志、IoT 传感器数据一上来就爆表
典型场景：每秒写入 5 万条设备心跳、App 端埋点日志按天增长 200GB、用户点击流不做聚合直接落盘。MySQL 单表过亿后 INSERT 明显抖动，主从延迟飙升到分钟级。这不是配置问题，是存储引擎的固有约束——B+ 树索引在超高频写入下会产生大量页分裂和锁竞争。NoSQL 的优势不在“快”，而在“不阻塞”：MongoDB 分片自动路由写请求，Cassandra 的 LSM-Tree 天然适合顺序写入。但注意：insertOne() 不等于零成本，若每条文档都带 10MB 图片 Base64，反而会拖垮网络和内存。
字段频繁变更，改个表结构要停服两小时
运营提需求：“明天上线新活动，用户档案要加 7 个字段，含数组和嵌套对象”。而你的 ALTER TABLE users ADD COLUMN tags JSON, ADD COLUMN preferences TEXT 在千万级表上执行要锁表。NoSQL 的 schema-less 不是放任自流，而是把约束从数据库层移到应用层。MongoDB 允许同一集合里 {name: "Alice", level: 5} 和 {name: "Bob", level: 8, vip_tier: "gold", last_login: ISODate(...)} 并存，但代价是你得自己校验 vip_tier 是否只出现在特定业务分支，且历史数据迁移逻辑必须手动覆盖。
缓存穿透、热点 Key、实时排行榜卡死 Redis
别把 Redis 当 NoSQL 用。它本质是内存键值缓存，不是持久化数据库。当你发现 GET user:123:profile 频繁返回空，或 ZINCRBY leaderboard:day 1 uid:456 因单 key 热点导致 CPU 拉满，说明架构层级错位。正确做法是：用 Redis 抗读（user:123:profile）、用 MongoDB 存原始行为（events 集合按 user_id 分片）、用 PostgreSQL 做核心账户（强事务）。混合使用不是妥协，而是让每种存储各司其职——这点最容易被忽略，很多人一上 NoSQL 就想全量替换，结果订单状态更新丢失、积分对不上账。
