不止MySQL：认识9种宝藏数据库与选型指南

数据库这事，说起来挺有意思。我周围大部分人一提到数据库，第一反应就是MySQL，面试聊到存储方案也是开口闭口“我们用的MySQL”。不能说错，MySQL确实是应用最广的关系型数据库之一，但每次遇到有人把MySQL当成数据库世界的全部，我心里都会咯噔一下——兄弟，外面还有一大堆数据库，各有各的绝活，你不认识它们，将来遇到棘手的业务需求时就会很被动。今天我就把除了MySQL之外，很值得认识的9种数据库摊开聊一聊。不是要你全都用上，而是至少知道它们各自是什么、解决什么问题、适合什么场景，将来选型的时候心里有谱。

1. 为什么说只认识MySQL会耽误事？先想清楚数据库的分类逻辑

很多人对数据库的理解停留在“数据库就是存数据的一张表”，所以觉得只要会MySQL就够了。这个理解本身有个盲区：MySQL只是一类数据库的代表，它擅长的是“结构化数据、强一致性、事务型处理”。但现实中业务对数据的诉求五花八门——有的要极高并发读写，有的要海量日志分析，有的要全文搜索，有的要描述复杂关系网络，有的要跑在手机端连服务器都没有。用MySQL硬扛这些场景，要么性能堪忧，要么开发成本巨大。

从架构角度看，数据库大体可以分成几类，认识它们的分类逻辑比死记名字更重要：

• 关系型数据库（RDBMS）：以表和SQL为核心，强调ACID事务和强一致性，MySQL、PostgreSQL、SQLite都属于这一类。
• 键值型数据库（Key-Value Store）：以键值对为存储单位，读写性能极高，适合缓存、会话管理等场景，Redis是典型代表。
• 文档型数据库（Document Store）：直接存JSON/BSON这类半结构化文档，字段可以随意扩展，MongoDB最有名。
• 列式数据库（Column-Oriented）：按列存储数据，擅长海量数据的聚合分析，ClickHouse、HBase都归这里。
• 搜索引擎数据库（Search Engine）：用倒排索引实现毫秒级全文检索，Elasticsearch是这个领域的标杆。
• 图数据库（Graph Database）：把数据建模成节点和关系，处理社交网络、推荐关系这类场景有天然优势，Neo4j就是代表。
• 分布式关系型数据库（NewSQL）：在保持SQL和事务能力的同时，把存储和计算水平扩展出去，TiDB就是这类产品。

理解了这个分类，再看下面的9种数据库，你会很清楚它们各自的定位，而不是零散地被名词轰炸。

2. 关系型阵营里被严重低估的两个选手：PostgreSQL与SQLite

2.1 PostgreSQL：功能全面到有些“过分”的关系型老兵

PostgreSQL和MySQL是同龄人，但两者的路线差异很大。MySQL追求简单高效，PostgreSQL则把“功能完整”做到了极致。我第一次从MySQL切到PostgreSQL的时候，最大的感受是：这玩意怎么什么都有？复杂查询可以写窗口函数、递归CTE、LATERAL子查询；JSONB类型可以直接在数据库里处理半结构化数据；连地理空间数据都能通过PostGIS扩展直接做距离计算、范围查询。

举个具体例子。我做过一个门店运营项目，原始需求是“查每个区域最近30天销售额排名前10的门店”。MySQL的写法要借助变量加子查询，改了好几轮才跑通。PostgreSQL用窗口函数十几行搞定，而且执行计划一出来，索引走得很干净。再看JSON场景，业务方后来要求把每个订单的扩展属性存下来，字段还不固定。MySQL改表结构改到崩溃，PostgreSQL直接用JSONB列接住，再配合GIN索引，查询速度和改表成本都让人满意。

不过PostgreSQL不是没有缺点。它默认配置偏保守，新手如果不做调优，性能发挥可能不如预期；高并发写场景下它的性能虽然不差，但相比MySQL的一些成熟方案，运维经验积累的人也少一些。另外，中文资料和社区规模确实比MySQL小，排查问题时要多花点时间翻英文文档。如果你做的项目重度依赖复杂查询、JSON灵活性、地理信息，完全可以试试PostgreSQL，同时保留MySQL做简单直接的业务读写，两个各有分工。

2.2 SQLite：被误解成“玩具”，其实是全球装机量第一的数据库

很多人一听SQLite——不就是个嵌入到程序里的轻量数据库嘛，能有什么大用？但事实是，手机上几乎每一个App、浏览器内部、不少桌面软件的本地存储，背后都站着SQLite。它不需要独立的服务器进程，数据库就是一个文件，驱动直接读写这个文件，既轻便又可靠。

我做过一个物联网边缘网关的项目，设备端没有条件装MySQL，但又需要本地暂存一段时间的数据，包括温度、湿度、状态事件等，还要支持增量上报。SQLite派上用场了：单个文件，几百KB的占用，支持标准SQL，还有WAL模式可以提升并发读写能力。现场人员拷贝这个文件就能做数据备份，出问题时直接把文件拿回来分析，非常省事。

SQLite的关键限制在于：它是单写多读模型，同一时刻只能有一个连接写数据，适合低并发场景，不适合作为高并发服务的后端存储。但如果你做桌面工具、移动端、嵌入式设备，或者需要一个零部署的临时存储，SQLite是少有的“不用求人就能搞定”的方案。它和Redis、MySQL之间的关系不是竞争，而是分工不同。

3. 非关系型三巨头：Redis、MongoDB与Cassandra，为什么它们能跑在MySQL前面？

3.1 Redis：不只是缓存，它还是一个数据结构服务器

Redis在多数项目里的角色是“缓存层”，但你要只把它当缓存用，其实浪费了它一大半能力。Redis可以存储字符串、哈希、列表、集合、有序集合、位图、HyperLogLog、地理坐标、流数据等多种结构，并且每条命令都是原子操作。这意味着很多需要“内存级速度”的业务逻辑，可以直接在Redis里完成，而不是先读MySQL再算。

举个例子，做排行榜、计数、限流这类功能，用Redis的ZSet、INCR、滑动窗口脚本，几十行代码就能上线。有人把秒杀场景的库存扣减也放在Redis里，依靠Lua脚本保证原子性，再异步写回MySQL，这个做法在流量很大的场景下是被验证过的。Redis还支持RDB和AOF两种持久化，虽然它不是做冷数据存储的首选，但配合主从复制、哨兵、集群模式，作为高可用缓存完全没有问题。

使用Redis要注意的是它的内存成本：数据都在内存里，量大之后成本很高，需要规划淘汰策略（LRU、LFU）和内存上限。另外，Redis 6.0以后引入多线程IO，但核心命令执行仍然是单线程的，所以设计上还是要减少耗时的KET和批量操作，避免阻塞。

3.2 MongoDB：写起来像JSON，业务扩张时少改很多表

MongoDB是最容易上手的非关系型数据库，因为它存储的文档长得就像你代码里的JSON对象。之前做内容社区系统时，文章有多种形态——图文、视频、问答、投票，字段差异很大。如果用MySQL，要么搞出N多张关联表，要么把一堆可空字段堆在一张大表里，后期维护真的头疼。MongoDB里直接一个集合存所有文档，不同类型的文档字段结构可以完全不一样，查询时按需要筛选，开发效率高了一截。

MongoDB的索引能力也超出了很多人的刻板印象：支持单字段索引、复合索引、数组多键索引、文本索引、TTL索引（自动过期删除）等。副本集提供高可用，分片集群可以做水平扩展。它的公司和团队用得非常多，常见于用户画像、Feed流、订单快照这类业务。

它不适合强事务、强关联查询的领域。虽然MongoDB 4.0以后引入多文档事务，但性能和场景定位决定了它更适合“文档敏捷模型”。另外，MongoDB对内存和磁盘IO也比较敏感，需要关注慢查询和索引优化，不能真的把它当成“无限扩张的JSON仓库”。最好的方式是：确认你的数据模型是文档化的，再考虑使用它，数据间如果全是复杂的JOIN关系，还是老老实实用MySQL或PostgreSQL。

3.3 Cassandra：把“写”做到了极致，天生就是分布式的

Cassandra是个很有意思的数据库：它去中心化，没有主从之分，每个节点地位平等，数据通过一致性哈希算法分布在多个节点上，写能力随节点增加近似线性扩展。它的设计目标是：永远不要有单点故障，磁盘随便坏，节点随便加，集群始终保持可用。

这种情况适合的业务场景包括：消息记录存储、行为日志流水、IoT设备上报数据、时序类写入量极大的场景。比如一秒钟几十万条状态写入，MySQL即使分库分表都很难顶住，Cassandra可以轻松抗住，配合适当的副本因子还能保证容灾。

不过你要做好心理准备：Cassandra的查询模型非常受限，它的分区键决定数据如何分布，查询最好都从分区键出发，不支持常规意义上的JOIN、聚合操作，也没有外键约束。Cassandra的数据模型设计思维跟MySQL完全不一样，要先明确查询模式再建表。很多人用不好Cassandra，是因为还在拿MySQL的关系型思维去套它，自然处处别扭。它的强项是“写入”，不是“复杂查询”。

4. 场景驱动的专用数据库：ClickHouse、Elasticsearch与Neo4j，用过之后有点回不去

4.1 ClickHouse：列式存储让大数据量聚合分析变得丝滑

我们需要区分OLTP和OLAP。MySQL这类以优化单行/小范围事务读写为目标，属于OLTP；而多维报表、大范围聚合、趋势分析这类场景，需要OLAP能力。ClickHouse就是OLAP领域的明星。

它采用列式存储，每一列独立压缩存储，查询时只需要读取涉及的列，极大减少了IO。加上极致的向量化执行引擎，几十亿行数据做GROUP BY、窗口计算时，常常能达到毫秒到秒级响应。我做过一个流量分析平台，每天采集数亿条访问日志。最开始用MySQL跑“按小时统计PV/UV”这种报表，跑到凌晨都结束不了，业务方天天催。后来把日志写入ClickHouse，同样的统计语句分分钟出结果，而且支持按任意维度切片，写SQL的感觉和MySQL很像，迁移成本极低。

ClickHouse的短板在于：不适合高频单行更新，事务能力较弱，并发更新场景表现一般。用法是把数据批量写入，然后用SQL做大规模分析。典型的组合方式是：MySQL负责业务事务，ClickHouse负责日志、明细、指标分析，中间用数据同步工具把数据灌过去。

4.2 Elasticsearch：全文检索和日志分析的事实标准

你自己在电商网站搜索框输入关键词，为什么能毫秒级看到匹配结果？背后八九不离十是Elasticsearch。它基于倒排索引，把文档分词后建立词到文档的映射，查询时直接找词，再合并文档列表，速度非常快。

Elasticsearch的生态很完整：Logstash负责日志采集和清洗，Kibana负责可视化，Beats负责轻量数据采集，合起来就是大名鼎鼎的ELK（现在常叫Elastic Stack）。排查生产问题时，到Kibana里搜关键字、查链路日志、生成统计图表，几乎成了日常操作。业务系统里的商品搜索、订单搜索、甚至“模糊搜客户”需求，也是Elasticsearch的强项。

使用中常见的一个坑是：Elasticsearch的写入成本较高，大批量日志需要做缓冲和批量写入，不能频繁大量地逐条写。另一个坑是分片数设置要谨慎，过多分片会带来集群维护压力，过少又可能影响横向扩展。它是一个搜索引擎，不是全能存储，不要把核心业务数据全塞进去然后期待它保证强一致。合理架构是：业务库写MySQL，日志库写Elasticsearch，搜索索引也放Elasticsearch，形成多套存储各司其职。

4.3 Neo4j：关系网络用“图”来建模，很多复杂查询会变得简单

提到“关系型数据库”，说的是表与表之间的关系，但查多层关系（比如朋友的朋友的朋友）时SQL很容易写得冗长且效率低下。图数据库Neo4j把人和人、人和物的连接直接建模成图的“边”，查询时沿着边遍历，直觉又高效。

我参与过一个人脉推荐项目，目标是给用户推荐“朋友的朋友”里他们还不认识的人，并且限制不超过三度关系。MySQL版本里递归查至少写几百行SQL，实际跑起来的性能还很感人。换Neo4j后，一个MATCH语句就能表达从起点沿关系路径遍历到三度的请求，配合关系的方向、类型、属性过滤，非常直观。Neo4j还特别适合知识图谱、反欺诈风控、供应链溯源、身份关系挖掘等场景。

Neo4j并不适合所有场景。它的强项是“关系深、路径查询多”，如果只是简单的一层关联查询，MySQL、ClickHouse都够用了，没必要引入图数据库增加运维成本。但一旦业务真正触及复杂关系网络，Neo4j带来的效率提升是“降维打击”级别的。

5. 新一代分布式关系型数据库：TiDB，既要SQL强一致又要水平扩展

TiDB近几年火起来，核心思路是“把MySQL的体验和分布式架构的扩展性结合起来”。它兼容MySQL协议和SQL语法，很多MySQL应用几乎可以不改代码就迁过来，同时它又具备分布式存储、自动分片、在线扩容能力，上层还能保证事务和强一致。换句话说，它把关系型数据库的“舒适感”和NoSQL的“扩展性”整合在了一起。

我之前维护过一个订单系统，用户量涨得快，订单表经常要分库分表，每次拆分都要做数据迁移，还要在应用层改路由规则，开发很烦。如果一开始用TiDB，这个问题会简单很多：数据自动分片，扩容节点即可，应用层不需要感知底层分片细节，仍然写普通SQL，事务照样用。TiDB底层用Raft协议保证多副本强一致，节点故障自动切换，对运维来说相当省心。

当然TiDB也有自己的适用边界：节点多了之后，分布式事务的开销不可避免，要求极低延迟的单行点查场景未必比单机MySQL快；它更适合“数据量会超出单机承受范围，但又不希望放弃SQL和事务”的业务。另外它部署起来比单机数据库复杂，需要有配套的监控、Placement Driver（PD）这几个组件一起玩。

6. 从认识数据库到选型：看到新项目需求，如何快速锁定合适方案？

我见过不少项目的悲剧来自“公司规定只能用MySQL”。实际上选型不该一开始就定死，而是先做需求拆解。可以按这几个维度过一遍：

• 数据形态：数据是结构规整的还是字段多变的？规整优先考虑关系型，多变考虑文档型。
• 一致性要求：资金、订单、库存这类强一致场景别碰无事务能力的NoSQL；缓存、计数值、Feed流这类允许一致性稍弱的，可以放心上用Redis、MongoDB。
• 并发读写模式：高写入低复杂查询，考虑Cassandra或时序类数据库；复杂报表分析，考虑ClickHouse；全文搜索，考虑Elasticsearch。
• 数据量级和扩展方式：数据能不能在单机装下？如果监测到“以后必须分库分表”的趋势，那就趁早评估TiDB这类分布式方案。
• 团队熟悉度：再好的数据库，团队不熟，上线后没人能维护，也是灾难。选型不能只看技术上限，还要看团队的学习成本。
• 运维成本：有的数据库比如Cassandra、TiDB，搭建和运维复杂度明显高于MySQL，小团队要有心理准备。

拿我之前做的一个新项目来举例：业务需要支撑用户注册、内容发布和实时搜索。当时没有纠结“非用MySQL不可”，而是选择了MySQL做用户和交易类核心数据，MongoDB存发布的内容草稿和灵活字段，Elasticsearch做搜索，Redis做热数据和会话缓存。上线之后整体很顺手，每个组件都在自己最擅长的位置。

7. 几种数据库的对比速查：一张表看懂它们的分工

如果看上面的内容还是有点犯晕，我整理了一张对比表，把几个关键维度放在一起，方便你按需检索：

这张表不是标准答案，但可以帮你快速建立“什么场景优先考虑什么数据库”的直觉。真正做选型时还需要结合具体的数据模型、团队能力、预算和运维条件。

8. 给正在学数据库的人几点个人建议

我不太建议一上来就把这10种数据库全学一遍，那样只会浅尝辄止。更务实的路径是这样的：先把MySQL用透，索引机制、事务隔离级别、锁、主从复制、慢查询优化这些核心知识搞定。然后再学一个文档型和键值型，MongoDB和Redis是很好的入门选择，因为它们的学习曲线平缓，能让你快速理解“非关系型”和“关系型”的区别。之后按业务需要，再接触ClickHouse、Elasticsearch、TiDB这些“专才型”数据库。

每个人的路径不同，但有一点我觉得挺重要的：不要觉得“多学数据库”是负担。实际上，每种数据库都是一套解决问题的思维模型。认识多了之后，你会发现自己在做技术方案时更从容，能像个有经验的人一样说“这个你用MySQL不合适，试试ClickHouse”或者“这个查询逻辑用Neo4j会好很多”。这种底气不是背名词背出来的，是理解它们的本质之后自然长出来的。