聊聊关系型数据库：从原理到现实挑战

如果你用过电商 APP 下单、在社交平台发动态，或是在银行 APP 查余额，背后都有数据库在默默工作。而在数据库家族里，关系型数据库曾是绝对的 “主角”—— 它帮我们管好账单、存好聊天记录，支撑了互联网早期的大部分业务。但随着数据量爆炸式增长，它的 “短板” 也逐渐显露。今天我们就从基础入手，聊聊关系型数据库的来龙去脉、核心能力，以及它为什么会遇到 “成长的烦恼”。

一、数据库的 “进化史”：从 “树状” 到 “表格”

要理解关系型数据库，得先看看它的 “前辈”—— 毕竟技术的发展，往往是为了解决上一代的痛点。数据库的核心是 “逻辑模型”，简单说就是 “用什么结构存数据”，这直接决定了数据好不好用、能不能适应业务需求。

1. 层次型数据库：像棵 “倒过来的树”

最早的数据库是 “层次型” 的，结构特别像老家的家谱 —— 顶端是 “根节点”，往下分 “子节点”，每个子节点只能有一个 “父节点”。比如早期银行存客户信息，“总行” 是根节点，下面挂 “分行”，分行下面挂 “储蓄所”，储蓄所下面才是 “客户账户”，一层套一层，逻辑很清晰。

当时最典型的就是 IBM 的 IMS 系统，上世纪 60 年代就开始用，很多银行、航空公司靠它管理数据。但问题也很明显：如果想查 “同一个客户在不同分行的账户”，就麻烦了 —— 因为两个账户分属不同的 “子节点”，没法直接关联，只能绕一大圈查询。而且一旦业务变复杂，比如要加 “理财产品” 关联客户，整个 “树结构” 就得大改，灵活性太差。

2. 网状型数据库：试着 “打破树形限制”

为了解决 “只能一个父节点” 的问题，网状型数据库应运而生。它允许一个 “子节点” 有多个 “父节点”，就像一张交织的网。比如在图书馆系统里，一本书可以同时属于 “计算机类” 和 “科普类”，一个作者也能关联多本书 —— 这种 “多对多” 的关系，用网状模型就能直接表示。

最具代表性的是基于 CODASYL 标准开发的系统，上世纪 70 年代在企业里挺流行。但新问题又来了：这张 “网” 太容易变复杂了。比如一个电商系统，要关联 “商品、订单、用户、库存、物流”，最后会变成一张密密麻麻的 “网”，程序员想查 “某个用户 3 个月前买的商品有没有售后”，得绕好几个节点，写代码时很容易出错，后期维护更是头疼。而且没有统一的查询语言，不同系统的操作方式天差地别，换个数据库就得重新学。

3. 关系型数据库：用 “表格” 拯救复杂

直到 1970 年，IBM 的研究员 E.F.Codd 发表了一篇论文，提出了 “关系模型”—— 把数据存在二维表格里，就像 Excel 表一样，每行是一条记录，每列是一个属性，再用 “主键”（比如身份证号）和 “外键”（比如订单里的用户 ID）把不同表格连起来。

这个想法一下子解决了之前的痛点：比如 “用户表” 存姓名、ID，“订单表” 存订单号、用户 ID、金额，要查 “用户的所有订单”，只需要通过 “用户 ID” 把两张表 “连起来” 就行，逻辑清晰，操作简单。后来出现的 MySQL、Oracle、SQL Server，都是基于这个模型。

我之前在做一个小型电商项目时，用 MySQL 建了 5 张表：用户、商品、订单、购物车、地址。比如用户下单时，先查购物车表获取商品 ID，再关联商品表确认库存，最后生成订单表记录 —— 整个流程靠 SQL 语句就能搞定，不用像之前那样纠结 “节点怎么连”。这也是为什么过去几十年，关系型数据库成了企业的 “标配”。

二、关系型数据库的 “核心技能”：它凭什么能火这么久？

关系型数据库能占据主导地位，靠的是一套成熟的 “核心功能”，这些功能就像它的 “基本功”，能稳稳托住企业的业务需求。

1. 数据 “规矩存放”：结构化存储

它要求数据必须 “按规矩来”—— 比如 “用户表” 里，“手机号” 列只能存 11 位数字，“邮箱” 列必须带 @符号，“创建时间” 得是日期格式。这种 “结构化” 就像给数据定了 “身份证”，不会出现 “手机号里混着字母”“年龄存成负数” 的情况，后续查数据、改数据都很省心。

我之前帮一个小公司做客户管理系统，用 PostgreSQL 建表时，给 “客户等级” 列设了 “只能是普通、VIP、钻石” 的约束，后来员工录入时不小心填了 “高级”，系统直接报错，避免了无效数据混入 —— 这就是结构化存储的好处。

2. 改存储不影响用：数据独立性

这是个很实用的功能，分 “物理独立” 和 “逻辑独立”。比如公司原来把数据库存在本地服务器，后来迁到云服务器（物理存储变了），但员工用的 APP 不用改任何代码，这就是 “物理独立”；再比如 “用户表” 里加了个 “会员到期时间” 列（逻辑结构变了），原来查 “用户姓名 + 手机号” 的功能照样能用，不用改代码，这就是 “逻辑独立”。

之前公司迁云时，我负责数据库迁移，原本以为要改很多代码，结果发现因为 “数据独立性”，只需要改下数据库地址，APP 完全不受影响，省了大麻烦。

3. 保证数据 “不出错”：完整性约束

它有一套 “防错机制”，比如 “主键约束” 确保每个用户的 ID 唯一，不会出现两个用户用同一个 ID；“外键约束” 确保订单里的 “用户 ID” 一定在 “用户表” 里存在，不会出现 “订单属于不存在的用户” 的情况。

之前做电商项目时，有次测试人员故意在订单表填了个不存在的用户 ID，结果系统直接拒绝，避免了 “幽灵订单”—— 这就是约束在起作用。

4. 统一 “操作语言”：SQL

不管是 MySQL 还是 Oracle，都能用 SQL 语言操作 —— 查数据用SELECT，加数据用INSERT，改数据用UPDATE。比如要查 “2024 年 1 月的所有订单”，不管用哪个数据库，写的 SQL 语句都差不多。这就像大家都讲普通话，程序员换个数据库不用重新学 “方言”，上手很快。

5. 操作要么成要么败：事务 ACID

这是关系型数据库的 “杀手锏”，尤其对金融、电商这类敏感业务太重要了。比如银行转账，“从 A 账户扣 1000 元” 和 “给 B 账户加 1000 元” 必须同时成功，要是中间断电了，系统会自动回滚，不会出现 “A 扣了钱但 B 没收到” 的情况 —— 这就是事务的 “原子性”；而且转账后，A 的余额减少、B 的余额增加，总金额不变，这是 “一致性”；同时有其他人查 A 的余额，不会看到 “扣了一半的中间状态”，这是 “隔离性”；转账成功后，就算系统崩溃，数据也不会丢，这是 “持久性”。

之前做支付功能时，就靠事务 ACID 保证了 “下单扣库存、付款减余额” 的准确性，没出现过一次账目混乱。

三、关系型数据库的 “优点”：为什么企业爱用它？

除了基本功扎实，它还有几个 “闪光点”，让企业愿意长期依赖它。

1. 复杂查询 “轻松搞定”

比如要查 “2024 年第二季度，VIP 用户购买金额超过 5000 元的商品，且这些商品的库存少于 10 件”—— 这种多条件、多表关联的查询，用 SQL 写几行代码就能实现。我之前帮运营做数据分析时，经常写这种复杂查询，几分钟就能出结果，不用自己手动算。

2. 数据 “绝对靠谱”

对金融、医疗这类行业来说，数据错一点都不行。比如医院的病历系统，用关系型数据库存数据，靠 ACID 和约束保证 “病历不会丢、不会改乱”；银行的账单系统，靠它保证 “每笔交易都准确”—— 这是很多数据库替代不了的。

3. 生态 “成熟稳定”

这么多年下来，关系型数据库的 “配套设施” 很全：有现成的备份工具、监控工具，遇到问题能在网上找到一堆解决方案，招聘时也容易找到会用的人。之前公司数据库出了个小故障，我在 Stack Overflow 上搜了下，很快就找到解决办法，不用自己瞎琢磨。

4. 安全 “有保障”

它能精确控制谁能看什么数据 —— 比如普通员工只能看客户的姓名和手机号，不能看客户的身份证号；管理员能改数据，但操作会留日志，出问题能追溯。之前帮一个医疗公司做系统时，就用 Oracle 的权限管理，确保医生只能看自己患者的病历，保护了隐私。

四、关系型数据库的 “烦恼”：为什么现在不够用了？

但随着互联网发展，数据量从 “GB 级” 涨到 “TB 级”“PB 级”，访问量从 “每秒几百次” 涨到 “每秒几十万次”，关系型数据库的 “短板” 也越来越明显。

1. 网络发展让它 “扛不住” 了

（1）想扩容量？太难了

传统关系型数据库像 “一间屋子”，东西多了只能往屋里塞更大的柜子（垂直扩展，升级硬件），但柜子再大也有上限；想多盖几间屋子（水平扩展，加服务器），又发现屋子之间没法同步数据 —— 比如你在 A 服务器存了用户 A 的订单，在 B 服务器存了用户 A 的购物车，查 “用户 A 的订单 + 购物车” 就得跨服务器，速度慢还容易出错。

之前有个做社交 APP 的朋友，早期用 MySQL，用户涨到 100 万时，服务器就扛不住了，想加服务器，结果发现数据同步是个大难题，最后只能临时升级硬件，花了不少钱。

（2）分片？越分越乱

为了解决扩展问题，有人想了 “分片” 的办法 —— 把数据分成几块，比如按用户 ID，1-10000 的存在服务器 A，10001-20000 的存在服务器 B。但这会带来新问题：如果要查 “所有用户的总订单量”，就得先查 A 再查 B，再汇总，速度慢；而且要是用户 ID 到了 20001，得再加服务器，迁移数据时还得停机，影响用户使用。

（3）分布式事务？搞不定

比如用户在 APP 上下单，订单存在服务器 A，库存存在服务器 B，扣库存和生成订单得同时成功 —— 但关系型数据库的 ACID 在分布式环境下不好使，很容易出现 “订单生成了，库存没扣” 的情况。之前有个电商平台搞促销，就因为这个问题，出现了 “超卖”，最后只能给用户赔钱。

（4）花钱如流水：许可费太贵

像 Oracle 这种商用数据库，是按服务器数量收费的，要是搞 10 台服务器集群，一年的许可费可能要几十万，对小公司来说根本扛不住。很多小公司只能用免费的 MySQL，但遇到复杂问题，没官方支持，只能自己扛。

2. 这些场景它 “玩不转”

（1）非结构化数据？存不了

现在的 APP 里有大量图片、视频、长文本（比如朋友圈的文字 + 图片 + 定位），这些 “非结构化数据” 没法按表格存 —— 你总不能把一张图片拆成 “像素 1、像素 2” 存到列里吧？之前帮一个短视频 APP 做存储方案，发现用 MySQL 存视频链接还行，存视频本身根本不现实，最后只能用对象存储。

（2）高并发写入？扛不住

比如双十一零点，每秒有几十万用户下单，关系型数据库的 “锁机制” 会拖慢速度 —— 比如多个用户抢同一个商品，系统得 “锁” 住库存，一个一个处理，结果就是后面的用户得排队，甚至出现 “卡死”。之前有个电商平台双十一时，就因为 MySQL 并发写入太慢，导致很多用户下单失败，损失了不少订单。

（3）改表结构？得停机

如果业务变了，要给表加个列，比如给 “用户表” 加 “短视频偏好” 列，就得先停机，改表结构，再重启 —— 这在现在 “7×24 小时在线” 的 APP 里根本行不通。之前公司想给用户表加个字段，只能选在凌晨 3 点操作，还得提前发公告，特别麻烦。

（4）全球部署？延迟高

如果公司业务遍布全球，用户在国外打开 APP，要访问国内的数据库，延迟会很高 —— 比如美国用户查订单，数据要跨太平洋传输，可能要等好几秒，体验很差。但关系型数据库很难做到 “就近存储”，因为数据同步太复杂。

写在最后

关系型数据库就像 “老伙计”，它用扎实的基本功支撑了互联网的早期发展，帮我们解决了无数业务难题。但随着数据量、并发量的爆炸式增长，它的 “短板” 也越来越明显 —— 就像马车再快，也跑不过汽车。

而 NoSQL 数据库的出现，正是为了弥补这些短板 —— 它能存非结构化数据，能轻松水平扩展，能扛住高并发写入。下一篇，我们就来聊聊 NoSQL 数据库到底是什么，它是怎么解决这些难题的。

如果你用过关系型数据库，或者遇到过它的 “坑”，欢迎在评论区聊聊你的经历～