大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

我刚入行时搜过“什么是关系型数据库”，出来的文章不是太长，就是术语堆成墙。定义背下来了，但别人一问“它到底怎么跑起来的”，我就卡住。后来我发现“关系”这两个字，得落到一张具体的表上才看得见。这篇我就用一张订单表讲，讲完你就能记住。

先说定义，**什么是关系型数据库？ 一句话就是把数据装进一张张互相有联系的表格，用 SQL 读写，靠 ACID 保证不出错。管理这些数据的软件，叫关系型数据库管理系统，简称 RDBMS。**

说实话，我会较这个真，是被一个活儿逼的：单位有套跑了好多年的老系统，要从Oracle 迁到国产库。我第一反应是，里面那些SQL、存储过程，不会要全重写吧？这个疑问先放着，我把基础讲完，再回来解。

## 为什么数据要装进"表格"里

你手机里的通讯录就是一张表。每行一个人，每列一个字段，姓名、电话、备注，一眼就懂。关系型数据库借的正是这个直觉。1970年IBM研究员E.F. Codd提出关系模型，核心就是用二维表组织数据：行叫记录，列叫属性，表与表之间还能建立联系。这个“联系”，就是“关系”二字的由来。

那Excel不也是表，为什么还要数据库？差别在机制。Excel靠人维护，数据库靠机制保证；Excel几个人同时改就乱套，数据库能扛成百上千人并发；Excel上万行就卡，数据库靠索引查百万行也快；Excel坏了很难救，数据库有日志、有备份。把它想成一张“靠谱得多的超级表格”，你就懂它为什么无处不在。

那“数据库”这个词，平时到底指什么？很多人混着用。它有两层：一层指数据本身，也就是这些互相有联系的表格；另一层指管数据的软件，就是刚说的RDBMS。建表、查数据、设权限、做备份、扛并发，全是后者在干活。MySQL、Oracle，还有国产的金仓KES，都是软件这一层的代表。再往外数，数据、软件、管库的人凑在一起，才叫完整的数据库系统。日常嘴里的“数据库”，多半只指软件那层。

## 关系型数据库的"关系"，靠什么连起来

单看一张表还不够。关系型数据库真正值钱的地方，是表跟表之间怎么连。我刚转行的时候跟过一个社区团购项目，后台至少要管三种数据：谁买的、卖的什么、哪笔订单买了啥。拆开就是三张表。

用户表 user：

| 用户ID（主键） | 昵称  | 手机号         |
| -------- | --- | ----------- |
| U001     | 橘橘  | 138****0000 |

订单表 orders：

| 订单ID（主键） | 用户ID（外键） | 商品 | 金额 | 状态 |
| --- | --- | --- | --- | --- |
| 1001 | U001 | 草莓两盒 | 39.9 | 已支付 |

注意两个词。用户ID在用户表里是主键，用来唯一认出一行；它跑到订单表里，就成了外键。靠这个ID，两张表串了起来。用户和订单是一对多，一个人能下很多单；商品和订单是多对多，一单能买多件、一件能被多单买。前者用外键表达，后者要再建一张中间表。这些靠ID牵起来的关系，将来迁库时最怕断在半路，一断，数据就对不上。
![封面图片 (1).jpeg](https://developer.qcloudimg.com/http-save/yehe-12362123/8b86359f61417c6aa745a7e906827737.png)

新手常卡在一个问题上：为什么不把商品直接塞进订单表？因为同一款草莓会被一千个人买，塞一起就得重复一千次，改一次价格要改一千行。拆开存，商品只放一份，订单表记个商品ID就够。这份“拆表”的直觉，就是你以后听说的“范式”的起点。

拆完表，一批术语冒出来，我第一次见也懵。整理成一张对照，面试前扫一眼就够了：

| 术语 | 人话解释 |
| --- | --- |
| 关系 | 一张二维表 |
| 元组 | 表里的一行 |
| 属性 | 表里的一列 |
| 主键 | 唯一标识一行的字段 |
| 外键 | 指向另一张表主键的字段 |
| 关系模式 | 这张表的结构定义 |

## 数据库怎么听懂人话：SQL

表建好，怎么把数据取出来？靠SQL，关系型数据库的通用语言。全称Structured Query Language，结构化查询语言。名字唬人，语法接近英文，新手一两天就能上手。不过SQL也分“方言”，同一句换个库偶尔就不认，平时没事，真到迁库才磨人。

查橘橘买过什么，写出来长这样：

```sql
SELECT u.昵称, o.商品, o.金额
FROM 用户表 u
JOIN 订单表 o ON u.用户ID = o.用户ID
WHERE u.昵称 = '橘橘';
```

JOIN把两张表按关联字段拼起来。这对关系型数据库是基本功，对很多非关系型数据库却是难题。我第一次跑通JOIN，觉得数据库“活”了：表不是孤岛，一条SQL能把散在各处的数据串成答案。

表建好后，还能加索引和视图。索引像书的目录，数据多了没它，查询会慢得明显；视图把常用查询存成一张“虚拟表”，下次直接查。这两个词面试常被连着问，先混个脸熟。

SQL内部分了工。建表、改表结构叫DDL；增删改数据叫DML；查询叫DQL，SELECT就是它；控制谁能访问叫DCL。新手不用全记，用到再查。

## ACID这四个字母，保的是不出错

光会写SQL，保证不了数据不出错。两个人同时改同一笔订单，会不会乱？转账转到一半断电，账还平不平？这些事，得靠数据库的ACID。它有四个特性：原子性、一致性、隔离性、持久性。光背名字没用，记一个转账场景就够。

你给朋友转一百块，系统要做两件事：你账户扣一百，他账户加一百。任何一步出错，钱都对不上。扣了没加，钱凭空消失；加了没扣，钱凭空多出来。事务就是把这两步捆成一组，要么全成功，要么全回滚；跑到一半断电、报错，就整体退回转账前。这类成组操作不止转账，下单扣库存、支付回调改订单状态，也是同一个套路，数据库里都叫事务。

逐条看，这个"全做或全不做"是原子性；转完两边总额不变，是一致性；多人同时转账不互相干扰，是隔离性；一旦提交钱就真到账，是持久性。这套标准，换到国产库上也不缩水。KES这类产品做信创替换，扛的仍是同样的ACID底线，业务逻辑不用为"降级"买单。一句话：ACID 让"数据不能出错"从口号变成制度。

## 关系型 vs 非关系型，别再站队

看完定义，第二个高频追问就来了：那NoSQL呢，是不是更先进？这几年MongoDB、Redis很火，总有人说关系型数据库要过时。我的看法是：它们不是替代关系，是分工不同。

| 对比维度 | 关系型数据库 | 非关系型数据库（NoSQL） |
| --- | --- | --- |
| 数据模型 | 二维表，结构固定 | 键值、文档、图，结构灵活 |
| 事务能力 | 完整 ACID | 多数只保证最终一致 |
| 查询方式 | 擅长多表 JOIN | 按 Key 取快，JOIN 弱 |
| 扩展方式 | 纵向扩展为主 | 天然分布式，横向好扩 |
| 代表产品 | MySQL、Oracle、PostgreSQL、金仓KES | MongoDB、Redis、Cassandra |

落到具体场景，我会问自己三个问题。这笔数据错了能不能忍？订单、库存、余额不能忍，选关系型。数据之间关系复杂吗？订单连着用户、商品、物流，越复杂越该选关系型。要存的是结构化数据，还是海量非结构化内容？文章、图片、社交关系满天飞，才轮到NoSQL。

现实中很少有人二选一，常见做法是关系型扛交易、Redis扛缓存。有人会反问：Redis也能存订单啊。能存，可等你要跨表统计、月底对账，就知道难受了。缓存、埋点日志、用户画像这类数据，交给NoSQL更顺手。两个阵营都学一点，别只站一边。

## 真实世界里的关系型数据库长什么样

原理讲完，看看真实世界。用得最多的关系型数据库是Oracle、MySQL、PostgreSQL、SQL Server。SQL大致通用，学会一家换另一家上手很快，这是这个模型五十年的红利。想入门也一样：别一上来啃原理书，先装个库把SELECT练熟，再学建表。踩过几张真实表，回头读概念会快很多。

国内这两年多了个变量：信创。政务、金融、能源的核心系统，陆续被要求换成自主可控的国产库，开头我接的那个活儿就是这类事。你可能觉得，换库不就是把数据导过去？真做起来，不是这么回事。

我那会儿最怕的“全部重写”，真做评估才发现要拆开看。SQL有共通底子，不会推倒重来；真正磨人的，是老系统攒下的方言写法、存储过程、对象类型。这也是国产库拉开差距的地方。走得比较早的金仓KES（KingbaseES），主打“平迁”：从Oracle、MySQL迁过来的老系统，常用SQL语法、对象类型、存储过程大多能接住，真正要动手改的，只剩少数不兼容的边角。我原以为要扒层皮，结果要改的业务代码比预想少太多。

“平迁”听着玄，拆开是三个本事叠出来的。一个迁移省事：从Oracle迁、从MySQL迁，语法和对象都兜得住，不用推倒重来，这是它跟别的库最不一样的地方。一个形态齐全：集中式、分布式都覆盖，业务小上集中式省钱省心，量大了往分布式扩也有现成的路，一路不用换库。一个国产自主：信创要的正是这个底子。三个合起来，才是我记住金仓KES的原因。

别把国产库想成另一套东西。你刚学的表、SQL、ACID，到它身上照样管用。模型是通用的，产品只是外壳。

关系型数据库自己也在进化。云数据库把备份、扩容做成了服务；分布式架构让单机装不下的数据能水平扩展；融合型数据库想用一套引擎同时跑交易和分析。技术一直在变，二维表加 SQL 这个底座五十年没动摇。

## 新手最容易踩的坑

最后说三个最常见的坑，都是我见过、有的亲自踩过。

把Excel当生产数据库。订单、库存、客户资料全堆在表里，人一多就乱，谁改错一个单元格都没人知道。数据一旦要多人并发、要权限、要审计，就该尽早迁到真数据库。

建表不设主键。我见过一张表几万行全是重复数据，想删都删不干净。每张表都得有个唯一标识，这是底线。

把多对多硬做成一对多。我头回做项目图省事，把用户和他选的课塞进一个字段，需求一变，改表改到半夜。多对多要拆中间表，这个亏我替你吃过了。

## 总结

整篇讲下来，要带的其实就四样：表、主外键、SQL、ACID。表装数据，主外键把表串起来，SQL负责读写，ACID保证不出错。这四样凑在一起，才是"关系型数据库"能火五十多年的原因。不是守旧，是"数据不能出错"这件事，永远有人需要。

这套底子，放到今天的国产替换里一样成立。哪天你碰上类似的活儿，别先被“全重写”三个字吓住，就问两句：老系统那批SQL和存储过程，新库接不接得住？业务以后要长大，它有没有得扩？金仓KES的“平迁”，说的正是这两件事：把旧的接住，给未来留路。

学数据库时，哪个概念卡过你？评论区聊聊。我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


我刚入行时搜过“什么是关系型数据库”，出来的文章不是太长，就是术语堆成墙。定义背下来了，但别人一问“它到底怎么跑起来的”，我就卡住。后来我发现“关系”这两个字，得落到一张具体的表上才看得见。这篇我就用一张订单表讲，讲完你就能记住。

什么是关系型数据库？一张订单表看懂原理，老系统迁国产库要不要重写

零基础用一张订单表讲透什么是关系型数据库：二维表、主外键、SQL、ACID一次看懂，理清和NoSQL的边界。再落到国产替换，老系统从Oracle迁国产库要不要全重写？金仓KES的平迁讲清迁移省事、形态齐全、国产自主。

数据库

职业发展

后端

关系型数据库用表格存数据，SQL读写，ACID保证安全。主键和外键连接表间关系，JOIN跨表查询。与NoSQL相比更适合交易场景。国产库如金仓KES支持Oracle/MySQL平迁。表、主外键、SQL、ACID四要素是数据库核心。

数据库管理系统

关系型数据库

数据库管理

结构化数据

代码解释

云数据库

SQL Server

PostgreSQL

Cassandra

MongoDB

NoSQL

Redis

MySQL

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

什么是关系型数据库？一张订单表看懂原理，老系统迁国产库要不要重写-腾讯云开发者社区-腾讯云

什么是关系型数据库？一张订单表看懂原理，老系统迁国产库要不要重写

什么是关系型数据库？一张订单表看懂原理，老系统迁国产库要不要重写

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐