为什么在数据库里用外键就有性能问题，而在业务层保证数据一致性就没有性能问题

因为业务层做就意味着数据库不需要为这个事做事务保证，而是业务自己负责，通常来说业务层会使用消息队列、事务补偿等在一致性上做出让步的”柔性事务”来做。

一、在业务层保证数据一致性没有性能问题

因为业务层做就意味着数据库不需要为这个事做事务保证，而是业务自己负责，通常来说业务层会使用消息队列、事务补偿等在一致性上做出让步的”柔性事务”来做。这样一来业务关键路径上的逻辑将变轻，总体延迟和TPS数据更好看。当然如果你不想放弃强一致性的话，还是在数据库层做更好，业务层要干这事，那性能会惨不忍睹。

外键保证的是数据更新符合约束的定义，也就是更新过程中通过一些检查来避免和约束冲突的情况出现。

但是，就像我们会在代码里写assert一样，有一些情况是我们确信不会发生的，那就可以不要约束，或者自己加一些管理来做到约束，所以很多程序会通过应用层来保障写入数据不会违反约束，这么做当然繁琐，不如数据库本身可靠高效。

那么大家这么做的最大动机是啥，是提高执行速度？ “去掉外键约束是提高执行速度的最简单粗暴的办法”，速度先提升上来，有什么坑可以在应用层修修补补，虽然最后修补出来的结果不一定有数据库本身约束的情况快。

以上，去掉外键的原因不是它对性能影响最大，而是众多因素当中外键是较好改的一个。

延伸阅读：

二、数据库中的概念

Table：数据库中的表，下文称“table”或者“表”。

Column：表中的各个字段，下文称“column”或者“列”或者“字段”。

Row：表中的各条记录，下文称“row”或者“行”

Index：表中的索引，用户可以建立索引以便加速搜索，但是用户无法直接使用索引，下文称“index”或者“索引”。

View：数据库中的视图，一种由实际的表导出的可视化的表，并不实际存储。

Virtual table：虚拟表是一种表现得像表的对象，从SQL语句的角度看，虚表可以和表或者view一样操作，但是对虚拟表的查询或者修改操作会调用注册在虚拟表上的回调函数，虚拟表机制使程序可以提供类似于SQL的表的接口供SQL语句操作。隐藏在虚拟表下的数据结构可能是内存中的数据，或者通过即时运算得出的结果，或者是磁盘上的文件（比如CSV）。下文称“virtual table”或者“虚拟表”。

Shadow table：FTS（全文搜索）中所使用的每个virtual table，都有3-5个真实的数据库的table（分别名为%_content、%_segdir、%_segment、 %_stat、%_docsize，%是FTS virtual table的名字）来在实现，这些table被称为shadow table。

Trigger：数据库中的触发器，由修改数据库的事件触发的存储过程，下文称“触发器”或者“trigger”。

Schema：SQLite数据库的结构（有哪些table/index/view/trigger，分别有哪些字段），下文称“schema”。

Rowid：rowid是SQLite中的表隐含的一个column，是其内部id，在该表中少数，是SQLite中的元数据。

Statement：SQL语句。

Prepared statement：经过“预备”的SQL语句，所谓“预备”类似编译，可以再多次执行同一语句的时候加速（跳过“预备”过程）。

sqlite_master：sqlite数据库中维护的系统表，该表的b-tree的根页号永远为1，有5个列，分别是类型（table, view, index,trigger，四者之一）、名称、所在表名、根页号、SQL语句。

Journal：日志

Transaction：事务是用户定义的一系列数据库操作，要么全部执行，要么全部不执行。

Magic string：类似“魔数/幻数”，SQLite数据库文件特征头。

Fraction

Auto-vacuum：自动清空

Incremental-vacuum

BLOB：Binary Large OBject