朋友做电商后台，某天突然发现商品详情页加载变慢，查了一圈发现是 MySQL 查询订单关联数据时卡在 JOIN 上。他试着把用户最近浏览记录、购物车缓存这些非强一致性数据，挪到 Redis 和 MongoDB 里——结果页面秒开，服务器 CPU 掉了一半。
不是所有 NoSQL 都快，关键看你怎么用
NoSQL 本身不保证“读得快”，它是一类数据库的统称：Redis 是内存键值库，MongoDB 是文档型，Cassandra 是宽列，Elasticsearch 是搜索型。它们快，是因为舍弃了某些东西：比如 ACID、跨文档事务、复杂关联查询。换来的，是更直接的数据定位方式。
比如 Redis 查一个用户积分：
GET user:1024:score但别急着全切过去
有次帮一个内容平台优化文章推荐接口，他们把全文本塞进 MongoDB，用 $text 搜索关键词。结果一上量，CPU 直接飙到 95%，因为没建好文本索引，每次都在扫整个集合。后来加了 db.articles.createIndex({ title: "text", content: "text" })，再配合 $search，延迟从 800ms 压到 40ms 内。
这说明：NoSQL 的读性能，极度依赖数据模型设计和索引策略。你扔进去一堆嵌套文档却不建索引，和在 MySQL 里对没索引的 varchar 字段 like '%xxx%' 没啥区别。
常见误区：以为“不走 SQL”就一定快
有人把 MySQL 里一张千万级日志表导进 Elasticsearch，原以为能秒搜，结果写了个 range 查昨天的数据，却忘了加时间字段的 date 类型 mapping 和索引，结果 ES 每次都 fallback 到 scan——比 MySQL 还慢。后来改用 @timestamp 字段 + 时间范围分片，才真正跑出亚秒响应。
所以，“NoSQL 读取性能好吗”这个问题，答案其实是：取决于你读什么、怎么存、有没有压对它的优势点。查单条 ID？Redis 或 DynamoDB 真香；查带多条件聚合的报表？还是老老实实回 MySQL 或 ClickHouse 吧。