做后端开发或者运维时，经常要跟ref="/tag/426/" style="color:#C468A7;font-weight:bold;">数据库打交道。关系型数据库（比如 MySQL）大家熟，但实际项目里，越来越多场景用上了 NoSQL——比如用户行为日志存 MongoDB，秒杀库存用 Redis，物联网设备数据上 Cassandra。可一换数据库，连“怎么查”都得重新学。
MongoDB：文档式查询，像写 JS 对象
MongoDB 存的是 BSON 文档（类似 JSON），查起来不写 SQL，而是用 JavaScript 风格的对象语法。比如查所有状态为 active 的用户：
db.users.find({ status: "active" })想查邮箱以 @example.com 结尾的，就加正则：
db.users.find({ email: { $regex: "@example\.com$" } })再比如查最近注册的 5 个用户，跳过前 10 条（分页常见写法）：
db.users.find().sort({ createdAt: -1 }).skip(10).limit(5)Redis：键值对为主，查得快但“查”得少
Redis 不是传统意义的“查询型”数据库，它更像一个超快的内存字典。所谓“查询”，多数时候就是 GET 一个 key：
GET user:10086但如果用了 Hash 结构存用户信息，也能局部取字段：
HGETALL user:10086
HGET user:10086 name想批量查一批用户？用 MGET 最省事：
MGET user:10086 user:10087 user:10088注意：Redis 没有模糊查询或条件筛选，真要“按条件查”，得靠业务层维护索引（比如用 Sorted Set 存时间戳，用 Set 存标签），否则就得扫全量 key——这在生产环境是大忌。
Cassandra：宽列存储，查之前先想好主键
Cassandra 强调写入吞吐和高可用，但查询能力受限明显：它不支持 JOIN，也不支持任意字段 WHERE。一切查询必须围绕表的主键设计展开。
比如建了张订单表：
CREATE TABLE orders (
user_id UUID,
order_time TIMESTAMP,
order_id UUID,
amount DECIMAL,
PRIMARY KEY (user_id, order_time, order_id)
);那你能高效查的只有这些：
- 查某个用户的全部订单：
SELECT * FROM orders WHERE user_id = 123e4567... - 查某用户某时间段内的订单：
WHERE user_id = ... AND order_time > '2024-01-01' AND order_time < '2024-02-01'
但不能只查 order_time > '2024-01-01'——没指定 user_id，Cassandra 直接报错。
别踩坑：NoSQL 的“查”不是万能的
有人把 MySQL 的思维直接搬进 MongoDB，比如给几十万文档加 $text 全文索引，结果搜索慢得像卡顿的网页；也有人在 Redis 里存了上亿个 key，还天天用 KEYS * 扫描——线上一执行，服务直接雪崩。
NoSQL 的查询逻辑，本质是“用空间换时间，用设计换灵活”。查得快不快，八成取决于你建表/建结构时有没有想清楚：数据怎么来、谁来查、按什么条件查、频率多高。临时补索引、硬加查询字段，往往不如重设计一张表来得干脆。