Why Enterprises Shun Foreign Keys: Performance Risks and Alternatives

What is a foreign key?

A foreign key is a constraint that links a column in one table to the primary key or a unique key in another table, ensuring referential integrity.

Example tables:

<code>CREATE TABLE `student` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '学生id',
  `name` varchar(256) NOT NULL COMMENT '学生姓名',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表';</code>

<code>CREATE TABLE `score` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '成绩 id',
  `student_id` bigint(20) unsigned NOT NULL COMMENT '学生id',
  `score` int(20) unsigned NOT NULL COMMENT '分数',
  PRIMARY KEY (`id`),
  KEY `student_id` (`student_id`),
  CONSTRAINT `fk_student_id` FOREIGN KEY (`student_id`) REFERENCES `student` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表';</code>

These statements define a foreign key using

foreign key ... references ...

, linking

score.student_id

to

student.id

.

Foreign‑key constraints have two main rules:

The foreign‑key column must reference a primary key or unique key in another table.

The referenced value must exist in the parent table, preserving referential integrity.

In simple terms:

When inserting a row into

score

,

student_id

must already exist in

student

.

Deleting or updating a row in

student

will automatically cascade to

score

, keeping data consistent.

Why not recommend using foreign keys?

【Strongly enforced】Do not use foreign keys and cascade; all foreign‑key logic must be handled at the application layer.

Enforcing foreign keys means the database must check constraints on every insert, update, or delete. This slows write performance, and cascade updates can become a blocking operation, leading to a “Database Update Storm” under high concurrency.

A Database Update Storm occurs when many clients simultaneously perform massive updates, causing lock contention, possible deadlocks, and a sharp drop in database performance or even failure.

When data volume grows, sharding (splitting databases) is common, but foreign keys cannot span separate databases, making consistency even harder to maintain.

Therefore, foreign keys and cascade operations are unsuitable for distributed, high‑concurrency clusters; they may be acceptable for low‑concurrency single‑machine scenarios where consistency is paramount.

For practical learning, the author mentions an open‑source e‑commerce project built with SpringBoot 3 and Vue, hosted on GitHub (⭐ 60K) and a micro‑service version (⭐ 11K) that demonstrates modern cloud‑native architecture, Docker, and Kubernetes deployment. Links to the repositories and video tutorials are provided for deeper exploration.