MySQL 不用外键的话，如何让表起来关联

比如在用户表里面的ID，最好写成userId

与之关联的相册表里面对应一个userId即可实现关联

参考1：

表的关联，只是一种逻辑概念，本并不需要进行物理上的“硬绑定”，而且你所期望的关联，其实只是其数据上存在一定的联系而已，而这种联系实际上是在设计之初就定义好的固有逻辑。

所以在业务代码中实现的时候，只要按照设计之初的这种固有关联逻辑来“存/取”数据即可，并不需要在数据库层面进行“硬绑定”，因为在数据库层面通过使用外键的方式进行“硬绑定”，会带来很多额外的资源消耗来进行一致性和完整性校验，即使很多时候我们并不需要这个校验。

所以一般不建议在数据库中使用外键约束来保证数据的一致性和完整性。

参考2：

首先关于外键的作用与使用场景：

1.作用：通过数据库提供的外键功能，进行数据完整性和一致性的维护，避免借助外部力量维护；

2.使用场景：若是高并发大流量事务场景，使用外键可能容易造成死锁，以及数据库资源更快出现瓶颈，所以一般互联网行业不建议使用，多使用再企业内部，比如ERP软件，早期的MIS系统等

关于如何体现表与表之间的关联性和如何维护数据完整性和一致性：

1.关联性：那就是设计数据库的时候，要让所有人知道表与表之间的通过那个字段关联起来，所以字段名称命名上会做一些文章

2. 如何维护数据完整性和一致性：通过外部程序的力量，启用事务的方式，比如：

START TRANSACTION

UPDATE A SET co1=** …

UPDATE B SET A_co1=**…

COMMIT

注释：假设场景 A表的col1变成某值之后，B表中的A_col1字段也必须修改为对应的值…

外键的设计初衷是为了在数据库端保证对逻辑上相关联的表数据在 *** 作上的一致性与完整性。

优点：

精简关联数据，减少数据冗余

避免后期对大量冗余处理的额外运维 *** 作。

降低应用代码复杂性，减少了额外的异常处理

相关数据管理全由数据库端处理。

增加文档的可读性

特别是在表设计开始，绘制 ER 图的时候，逻辑简单明了，可读性非常强。

缺点：

性能压力

外键一般会存在级联功能，级联更新，级联删除等等。在海量数据场景，造成很大的性能压力。比如插入一条新记录，如果插入记录的表有 10 个外键，那势必要对关联的 10 张表逐一检查插入的记录是否合理，延误了正常插入的记录时间。并且父表的更新会连带子表加上相关的锁。

其他功能的灵活性不佳

比如，表结构的更新等。

---