一、前言
上一篇
SQL 第二篇：表结构设计（为什么企业要拆成 3 张表）
我们已经把三张表建好了：
user user_detail user_address但是很多人到这里会开始懵：
为什么 user_detail 里有 user_id？ 为什么 user_address 里也有 user_id？甚至很多人第一次学数据库时，会觉得：
数据库是不是会自动知道它们之间的关系？其实不是。
二、先说结论（这一篇核心）
数据库不会自动关联表
表之间的关系，是你自己设计出来的
而这个关系的核心：
就是 user_id三、user_id 到底是什么？
我们先看：
user 表
CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) );user_detail 表
CREATE TABLE user_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL UNIQUE, real_name VARCHAR(50) );这里：
user.id和：
user_detail.user_id实际上表示的是：
同一个用户四、user_id 本质是什么？
本质上：
user_id = “引用 user 表里的 id”比如：
user 表
| id | username |
|---|---|
| 1 | zhangsan |
| 2 | lisi |
user_detail 表
| id | user_id | real_name |
|---|---|---|
| 1 | 1 | 张三 |
| 2 | 2 | 李四 |
这里：
user_detail.user_id = user.id表示：
这份详情属于哪个用户五、数据库里的“关系”到底是什么？
很多初学者会误以为：
表和表之间真的“连”在一起其实不是。
数据库本质上：只是两张独立的表
真正让它们产生关系的是：相同的字段值
比如：
user.id = 1 user_detail.user_id = 1于是数据库就知道：
这两条数据有关联六、一对一关系（核心）
上一篇我们写过：
user_id BIGINT NOT NULL UNIQUE重点在：
UNIQUE为什么 UNIQUE 就是一对一？
因为：
同一个 user_id 只能出现一次例如：
正确
| id | user_id | real_name |
|---|---|---|
| 1 | 1 | 张三 |
错误
| id | user_id | real_name |
|---|---|---|
| 1 | 1 | 张三 |
| 2 | 1 | 张三2 |
第二条会报错。
因为：user_id 唯一
所以：
一个用户只能有一份详情这就是：
一对一关系七、一对多关系（核心）
再看 user_address：
user_id BIGINT NOT NULL注意：
没有 UNIQUE所以：
同一个 user_id 可以出现多次例如：
| id | user_id | city |
|---|---|---|
| 1 | 1 | 苏州 |
| 2 | 1 | 上海 |
| 3 | 1 | 北京 |
说明：
一个用户有多个地址这就是：
一对多关系八、为什么企业喜欢用 user_id？
因为：
数字ID稳定如果你用：
username做关联，会有问题：
用户名可能修改但：
id 一般不会变所以企业里：
关联字段基本都是 ID九、外键（FOREIGN KEY）到底是什么？
很多人学到这里又会看到：
FOREIGN KEY (user_id) REFERENCES user(id)这是什么意思？
含义
表示：
user_id 必须来自 user.id比如：
user 表
| id | username |
|---|---|
| 1 | zhangsan |
正确
user_id = 1因为：
user.id 里存在 1错误
user_id = 999因为：
user 表根本没有 999数据库会拒绝插入。
十、企业里为什么很多项目不用外键？
这个问题很经典。
原因：
1️⃣ 外键会影响性能
因为数据库需要额外检查：这个 user_id 存不存在
2️⃣ 分库分表后外键很难用
大型系统：
user和：
user_address可能不在一个库。
这时候：
外键无法使用3️⃣ 企业更多用“代码保证关系”
也就是：
userMapper.selectById(userId)先查用户是否存在。
十一、所以到底要不要用外键？
我的建议：
学习阶段
✔ 可以用
因为：
更容易理解表关系企业项目
很多项目：
不用外键而是：
逻辑外键即：
只保留 user_id
不真正建立 FOREIGN KEY
十二、这一篇真正的核心
这一篇最重要的不是：
UNIQUE FOREIGN KEY而是：真正理解了“数据库关系”到底是什么
十三、一句话总结
表关系的本质：
👉 用相同字段值，把两张独立的表关联起来
下一篇预告
下一篇正式进入：
SQL 第四篇：JOIN 实战（为什么表能拼起来）
真正讲透：
INNER JOIN LEFT JOIN ON以及：
数据库到底是怎么“拼表”的
