大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
上个月一个刚转行做数据开发的朋友问我："小耶，我听说有时序数据库、向量数据库、图数据库......这些和MySQL到底什么关系？我该从哪个学起？"
这个问题问到了根子上。很多人学数据库，一上来就扎进MySQL的语法里，结果学了半年发现还有个东西叫MongoDB，又学了三个月发现还有个东西叫Redis------永远在追，永远追不完。
今天不教你怎么写SQL，先画一张数据库的"家谱"，把整个数据库家族的关系搞清楚。这条路走通了，后面的学习就清晰了。
一、数据库的三种分类维度
数据库的分类方式不止一种。就像人可以用性别分、可以用国籍分、可以用职业分------数据库也可以从不同角度来划分。但最核心、最常用的分类维度有三个：按数据模型分、按业务负载分、按部署架构分。
一张订单表，按数据模型它是关系型的，按业务负载它是OLTP的，按部署架构它可能是集中式的。三个维度看的是同一件事的不同侧面，组合起来才能完整描述一个数据库的"画像"。
维度一：按数据模型分类
数据长什么样、怎么组织。关系型把数据塞进二维表格，非关系型用键值对、JSON文档、图关系等各种形态。
维度二：按业务负载分类
数据存进去是用来查的，但"怎么查"决定了数据库的设计方向。OLTP扛高并发短事务，OLAP做海量数据聚合分析。
维度三：按部署架构分类
数据放在一台机器还是拆在多台机器上协同工作，决定了系统的扩展方式和运维复杂度。
二、按数据模型分类：关系型与非关系型
这是数据库最顶层的分类------就像"动物"和"植物"一样。
关系型数据库（RDBMS）
1970年IBM研究员E.F. Codd发表了一篇论文，提出了关系模型。数据用二维表格组织，行是记录，列是字段，表与表之间通过主键和外键关联。它的核心优势是ACID事务、复杂SQL查询、数据强一致性。
你可以把关系型数据库想象成一个档案室，每个文件柜有固定的分类标签，每份文件按编号排列在固定的抽屉里。找一份文件，你只需要知道它的编号，就能顺着索引精确定位到它所在的抽屉。新增一份文件，你必须先确定它属于哪个分类，填好所有必填字段，再放进去。如果有一份文件缺了必填信息，档案室管理员会拒绝入库------这就是关系型数据库的Schema约束。
2026年DB-Engines排行榜上，前五名有四个是关系型数据库。MySQL是互联网标配，PostgreSQL功能最全面，Oracle和SQL Server在企业核心系统里地位稳固。国产方面，金仓KingbaseES在政务、金融、能源等行业快速落地，Oracle兼容度高，迁移成本相对可控。
非关系型数据库（NoSQL）
NoSQL的意思是"Not Only SQL"------不只是SQL。它在关系型之外开辟了多条分支，每种都有自己的适用场景。
键值型（Key-Value）
数据存成Key-Value对，根据Key查Value极快。Redis是典型代表。
你可以把它想象成字典------你知道一个字，直接翻到那一页，不用从头看起。字典里没有复杂的目录结构，只有"字→释义"的映射。这就是Key-Value模型：一个Key对应一个Value，查询速度O(1)，但你不能问"所有Value里包含某个关键词的Key有哪些"------字典不支持这种查法。
Redis适合缓存、Session存储、计数器，读写速度是磁盘的几十倍。它把所有数据放在内存里，所以快，但也意味着成本高、容量有限。
文档型（Document Store）
数据存成JSON/BSON文档，每个文档的字段可以不一样。MongoDB是典型代表。
你可以把它想象成一个档案袋------每个学生一个档案袋，张三的档案袋里有成绩单、体检表、家庭情况登记表，李四的档案袋里只有成绩单和体检表，没有家庭情况登记表。档案室管理员不会要求每个档案袋里的文件种类完全一致。这就是文档型数据库"无Schema约束"的核心：同一张"表"里的不同文档，可以有不同的字段结构。
MongoDB适合内容管理、日志存储、用户配置，支持在JSON字段上建索引，也能做多文档事务。
列族型（Wide-Column Store）
按列族组织数据，适合海量数据写入和查询。Cassandra、HBase是典型代表。
你可以把它想象成超市货架------每一列商品放在同一排货架上，你要找某种商品，直接去那一排，不需要整层楼逛一遍。传统行存是一条记录的所有字段放在一起，列族型是把同一列的数据集中存放。在分析场景下，你只需要读少数几列时，列族型比行存少读大量无关数据。
图数据库（Graph）
数据存成节点和边------节点代表实体，边代表关系。Neo4j是典型代表。
你可以把它想象成一张人际关系网------每个人是一个节点，每一条"认识""同事""朋友"是连接节点的边。你要查"张三的朋友中谁认识李四"，在关系网里顺着边跳两下就能找到答案。传统关系型数据库做同样的事情需要递归查询，层数越多越慢。图数据库在"朋友的朋友"这类多跳查询上比关系型快几十倍甚至上百倍。
图数据库适合社交网络、风控反欺诈、知识图谱等场景。
三、按业务负载分类：OLTP与OLAP
OLTP（在线事务处理）
订单、支付、用户注册、库存扣减------这类系统的核心诉求是"快"和"准"。特点是高并发、短事务、强一致。用户下单扣库存，必须保证不超卖。每秒上百笔交易，每笔只涉及几行数据，要求毫秒级响应。MySQL、PostgreSQL、Oracle是OLTP的典型代表。
你可以把它想象成便利店收银台------每个顾客买的东西不多，几样商品扫码结账，但排队的人一直不断。每一笔收据不能算错账，找零不能出错，否则顾客立刻投诉。这就是OLTP的约束：高频、快速、零差错。
OLAP（在线分析处理）
报表、大屏、数据仓库------这类系统的核心诉求是"全"和"深"。特点是数据量大、查询复杂、对响应时间容忍度高。业务方要"上个月各品类销售额TOP10"，OLAP数据库几秒钟就能算出来。ClickHouse、Doris是OLAP的典型代表。
你可以把它想象成超市月底盘点------不着急出结果，但数据量大，要把所有货架都数一遍，还要按品类汇总、按时间段对比。这种查询不需要秒级响应，几十秒甚至几分钟都能接受，但它要求数据库能快速扫描几千万行数据做聚合运算。
四、按部署架构分类：集中式、分布式与云原生
集中式
数据全部放在一台服务器上（或主从集群里），架构简单、运维成熟。适合数据量可控、事务复杂度高的场景。金仓KingbaseES、MySQL都是集中式的典型代表。
你可以把它想象成一家小卖部------一个老板、一个收银台、一个货架，忙得过来就够用。生意扩大之前，这套系统足够支撑。
分布式
数据自动分片到多台服务器，水平扩展能力强。适合数据量巨大（50TB以上）、写入并发极高的场景。OceanBase、TiDB是典型代表。你可以把它想象成连锁超市------每个分店负责一部分区域的顾客，数据分散存储，总部统一调度。
云原生
存算分离，计算节点无状态可独立扩缩容。适合云上弹性业务。PolarDB、GaussDB是典型代表。
五、专项数据库：为特定场景而生的"特种部队"
2026年的数据库家族还有一批"特种部队"，它们不在传统的关系型/非关系型分类框架里，而是为特定数据形态和查询模式独立发展出来的专用产品线。
时序数据库
专门处理带时间戳的数据------设备传感器读数、服务器监控指标、股票行情。数据每秒钟都在产生，查询永远围绕时间窗口展开，"过去24小时的平均温度""最近7天的峰值流量"是典型查询。InfluxDB、TDengine是代表产品。
你可以把它想象成工厂里的温度记录仪------每隔几秒自动记录一次温度，记录仪上只写时间和数值，不问"这条记录属于哪个批次、哪个班组"。查询时只关心"昨天下午3点到5点之间温度有没有超过警戒线"。时序数据库就是为了这种"只关心时间序列值"的场景而设计的，专门优化了高频写入和按时间范围的聚合查询。
向量数据库
存储AI模型生成的向量数据，做相似度搜索。RAG应用、以图搜图、推荐系统都在用。Milvus是典型代表。
你可以把它想象成指纹库------每个指纹是一串特征点（向量），你要找"和这个指纹最相似的人"，不需要精确匹配，而是找出特征点最接近的那几个。传统数据库的精确匹配在这里派不上用场，向量数据库专门解决这个问题：在海量高维向量中快速找到"最相似"的那一批。
六、2026年的新趋势：多模数据库
搞清楚上面所有分类之后，你会发现一个有意思的问题：如果业务同时需要关系型存订单、文档型存日志、向量型做AI检索，是不是要维护三套数据库？
2026年的答案是：不用。
多模数据库正在从概念走向规模化落地。一套数据库内核原生支持关系、文档、向量、图等多种数据模型。比如金仓KingbaseES V9在多模融合方面走得比较靠前，原生支持关系数据、JSON文档、向量数据、时序数据及GIS空间数据。跨模型查询在同一个SQL里完成，不再需要多套系统拼接。
传统方案需要为每种数据类型部署独立的数据库系统，数据孤岛林立、运维成本翻倍。多模数据库正在改变这个局面。
七、一张图看懂数据库"家谱"
八、总结
数据库的"家谱"看起来复杂，但理清楚之后就是一个三层的树形结构：
-
第一层：按数据模型、业务负载、部署架构三个维度划分
-
第二层：每个维度下面有不同的分支------关系型/非关系型、OLTP/OLAP、集中式/分布式/云原生
-
第三层：每个分支下面有具体的产品------MySQL、Redis、ClickHouse、TiDB......
2026年还有一个正在加速的趋势：多模融合。关系型、文档型、时序型、向量型正在被集成到同一个数据库内核中。传统上需要为每种数据类型部署独立数据库的做法，正在被"一库多模"取代。
每种数据库类型都有自己的适用边界和不可替代的理由。核心交易要准，缓存要快，图要查关系，向量要找相似------没有哪一种能通吃所有场景。选型的起点不是"哪个产品最好"，而是"你的业务数据长什么样、怎么查"。这个判断做对了，后面的选型才不会跑偏。
后面我们会逐个深入每一种数据库类型------从背景、原理到产品选型，一次讲透。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽......我们下次见~