关系型数据库是大多数人接触数据库的第一站。它的核心思路特别朴素——把数据塞进一张张二维表格里，行是记录，列是字段，表与表之间通过主键外键勾连起来。MySQL、PostgreSQL、Oracle、SQL Server，这些名字几乎成了数据库的代名词。你公司里的财务系统、订单系统、会员系统，十有八九跑在这类数据库上。它们最大的优点是稳，事务机制保证数据不会出现半截操作，银行转账扣了钱没到账这种事，在关系型数据库里基本不会发生。但稳的代价是灵活度差，表结构一旦定下来，改起来像给大象做整形手术。而且当数据量冲到千万级、上亿级，单表查询慢得让人抓狂，这时候你就得琢磨分库分表或者换赛道了。
非关系型数据库的崛起，本质上是对关系型数据库“管太多”的一种反抗。Redis把数据全塞在内存里，读写速度能跑到每秒十万次以上，做缓存、做计数器、做分布式锁，顺手得不行。MongoDB则把文档当基本单位，一个JSON对象就能存一条完整数据，字段可以随意增减，程序员再也不用为了加个标签字段去跑一遍ALTER TABLE。这类数据库还有个共同点——天生为分布式设计，水平扩展像搭积木。但你得接受一个事实：它们为了性能牺牲了强一致性，某些极端情况下可能会读到旧数据。所以选型时别被“快”冲昏头脑，先想清楚你的业务能不能容忍那几毫秒的延迟偏差。
键值数据库和文档数据库其实都算非关系型的子类，但应用场景差异巨大。键值数据库最极简，一个Key对应一个Value，连查询语法都省了，直接按主键取数据。Redis、Memcached是代表，适合存会话信息、用户偏好这种简单结构。文档数据库则像键值数据库的升级版，Value不再是模糊的字符串，而是有结构的JSON文档，还支持嵌套和数组。MongoDB、CouchDB就是典型。有趣的是，现在很多团队把Redis用成了全能选手，既当缓存又当消息队列，还当分布式锁的存储层，这其实挺危险——Redis的持久化能力有限，真把身家性命压上去，宕机时哭都来不及。
图数据库是专门为关系而生的数据库，它把数据建模成节点和边，节点代表实体，边代表关系。社交网络里的好友关系、风控系统里的资金流向、推荐引擎里的行为路径，这些场景天然就是图结构。Neo4j是这块的当红炸子鸡，用Cypher查询语言像写自然语言一样查关系：比如“找出跟张三有间接交易且交易金额超过十万的所有人”，一条语句就能搞定，换成SQL得写半天自连接。但图数据库的短板也明显——它不适合大规模聚合计算，数据量一旦上来，遍历路径的代价指数级增长。所以它通常只做核心关系查询，外围数据还是得放回关系型数据库。
时序数据库是为时间戳数据量身定制的，监控指标、传感器数据、股票行情、日志记录，全是按时间顺序产生、按时间范围查询的数据。InfluxDB、Prometheus、TimescaleDB这些名字你可能听过，它们最大的本事是高效压缩和快速聚合——几百万条数据点，按分钟、小时、天做降采样，秒出结果。传统关系型数据库面对这种“写多读少、按时间滚动”的场景会累得够呛，索引膨胀、存储浪费，查个半年前的数据得扫全表。时序数据库把时间维度当成核心索引，数据过期自动清理，还能做连续查询预计算。不过你要是拿它存订单数据，那就是杀鸡用牛刀了。
选型这件事，没有银弹，只有权衡。我见过不少团队，一上来就追时髦，听说MongoDB火就全迁过去，结果发现复杂的多表关联查询写不出来，又灰溜溜迁回MySQL。也见过死守Oracle不放，明明业务量小得可怜，还每年交着昂贵的授权费。核心原则就三条：第一，看数据模型——你的数据是结构化表格、文档、图还是时间序列？第二，看查询模式——是频繁更新单条记录，还是批量扫描聚合？第三，看扩展需求——是单机扛得住，还是必须水平扩展？把这三条想清楚，选型不会出大错。顺便提一句，现在云厂商的托管数据库服务越来越成熟，RDS、DynamoDB、CosmosDB，能帮你省掉运维的苦，但绑定了厂商，迁移成本得提前掂量。
数据库的世界远不止这几类，还有向量数据库专门存AI生成的嵌入向量，空间数据库处理经纬度坐标，多模数据库想一把梭全包圆。但万变不离其宗，每种数据库都是某种特定数据形态的优化解。你要做的不是记住所有类型，而是理解数据本身的形状——它像表格，就选关系型；像文档，就选MongoDB；像关系网，就选图数据库；像时间流，就选时序数据库。数据库没有最好，只有最合适，这个“合适”得靠你对业务的理解深度来定义。下次面试官问你“数据库都有什么”，你大可以甩出这篇文章的思路，再补一句：“但更重要的是，我知道我的数据该住在哪里。”
