本文详解 MySQL 外键约束的底层要求（被引用列必须是主键或唯一键）、典型错误 errno: 150 的根本原因，并通过修复示例演示如何规范定义多外键关联表。
本文详解 mysql 外键约束的底层要求（被引用列必须是主键或唯一键）、典型错误 `errno: 150` 的根本原因，并通过修复示例演示如何规范定义多外键关联表。
在 MySQL（尤其是 InnoDB 引擎）中，成功创建含多个外键的表，远不止语法正确即可——关键在于每个外键所引用的列，必须在目标表中具有唯一性保障。最常见的误区是误以为“只要列名存在就能建立外键”，而忽略了 SQL 标准及 InnoDB 的强制前提：被引用列必须是主键（PRIMARY KEY）或具有唯一约束（UNIQUE KEY）的索引列。
回顾原始建表语句中的关键错误：
CONSTRAINT fk_payment FOREIGN KEY(payment_id) REFERENCES users(payment_id)
此处 REFERENCES users(payment_id) 暗示 users 表中 payment_id 是其主键或唯一键。但现实中，users 表的主键几乎必然是 users_id；而 payment_id 很可能属于 payments 表（而非 users 表）。这直接违反了外键引用规则，导致 MySQL 报错 #1005 - Can't create table ... (errno: 150)。
✅ 正确做法需满足三点：
- 目标表结构先行验证：执行 SHOW CREATE TABLE users; 和 SHOW CREATE TABLE payments;，确认各被引用列是否为 PRIMARY KEY 或带 UNIQUE 索引；
- 引用关系逻辑自洽：order_details 应关联 order_items（订单条目）、users（下单用户）、payments（支付记录），而非重复引用 users 表两次；
- 数据类型与属性严格一致：外键列与被引用列的类型、长度、符号性（如 INT(10) UNSIGNED vs INT(10)）、字符集和排序规则必须完全匹配。
以下是修正后的建表语句（假设 payments 表存在且 payment_id 为其主键）：
CREATE TABLE IF NOT EXISTS order_details (
order_details_id INT(10) NOT NULL AUTO_INCREMENT,
order_items_id INT(10) NOT NULL,
users_id INT(10) NOT NULL,
payment_id INT(10) NOT NULL,
total DECIMAL(6,2) NOT NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
modified_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (order_details_id),
-- 正确：引用 order_items.order_items_id（需确保该列为 PK 或 UNIQUE）
CONSTRAINT fk_order_items
FOREIGN KEY (order_items_id) REFERENCES order_items(order_items_id)
ON DELETE CASCADE,
-- 正确：引用 users.users_id（通常为主键）
CONSTRAINT fk_users
FOREIGN KEY (users_id) REFERENCES users(users_id)
ON DELETE RESTRICT,
-- 修正：应引用 payments.payment_id（而非 users.payment_id）
CONSTRAINT fk_payments
FOREIGN KEY (payment_id) REFERENCES payments(payment_id)
ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;⚠️ 注意事项：
- ON UPDATE/ON DELETE 子句虽非必需，但强烈建议显式声明级联行为（如 CASCADE、SET NULL、RESTRICT），避免数据不一致；
- 若目标列尚未建索引，InnoDB 会自动为其创建索引；但若该列已存在非唯一普通索引，InnoDB 允许引用（属非标准扩展），不推荐依赖此行为——因其违背参照完整性语义（一个外键值可能对应多行父记录，语义模糊）；
- 建表前务必确认所有被引用表已存在、引擎均为 InnoDB（MyISAM 不支持外键），且字符集兼容（如统一用 utf8mb4）；
- 使用 SHOW ENGINE INNODB STATUS\G 可查看最近的 errno: 150 错误详情，定位具体哪一约束失败。
总结：多外键表并非“不可行”，而是对数据库设计规范性提出更高要求。严谨的实体关系建模 + 严格的列级约束验证，才是解决 errno: 150 的根本路径。将外键视为数据完整性的契约，而非语法装饰，方能构建健壮的业务模型。
