MySQL在执行建表或者添加外键的操作时，有时会抛出错误代码1022，提示信息通常为ERROR 1022 (23000): Can't write; duplicate key in table。这个错误并不是指数据行里的主键或唯一索引重复，而是外键约束的名字在整个数据库范围内出现了重复。InnoDB存储引擎要求外键约束名称在单个数据库内必须全局唯一，不少人在写SQL时习惯把外键写成fk_user_id这种简短名字，一旦多张表都使用相同名称，后执行的语句就会直接失败。
要理解1022错误的底层机制，需要先看MySQL对外键的元数据管理方式。外键信息记录在information_schema库的KEY_COLUMN_USAGE和REFERENTIAL_CONSTRAINTS两张表中，其中CONSTRAINT_NAME字段就是外键名。当一条CREATE TABLE或者ALTER TABLE语句试图注册一个新的外键名，而该名字已经存在于当前库的约束清单里，MySQL会在写系统表阶段报错并回滚当前DDL，这就产生了1022。它与存储引擎层的重复键值写入无关，纯粹是约束命名冲突。
很多自动化迁移工具默认用“fk_列名”生成外键，在单表内没问题，但跨表协作时极易撞名。例如订单表和用户表都给user_id字段建外键，若都叫fk_user_id，第二个表建表必然报1022。因此规范做法是在名称中加入表名缩写，如fk_order_user_id与fk_profile_user_id，从命名源头杜绝冲突。
如何快速定位引发1022的重复外键
遇到1022不要急着删表重来，第一步应当查清楚当前库里哪些外键名已经被占用。可以查询information_schema.KEY_COLUMN_USAGE视图，过滤CONSTRAINT_TYPE为FOREIGN KEY的记录，并按TABLE_SCHEMA限定当前数据库。这样能列出全部外键及其所属表，肉眼比对报错语句中的外键名即可找到重复项。
下面是一段实用的排查SQL，假设当前库名为test_db，要找名为fk_user_id的外键落在哪张表上：
SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE CONSTRAINT_TYPE = 'FOREIGN KEY' AND TABLE_SCHEMA = 'test_db' AND CONSTRAINT_NAME = 'fk_user_id';
执行后若返回多行，说明外键名确实重复。如果返回空但建表仍报1022，需检查是否在同一个语句里对同表创建了同名外键，或者前面某次失败的事务残留了元数据。此时也可查REFERENTIAL_CONSTRAINTS表确认约束是否真实存在。明确冲突点之后，就能决定是改名还是先DROP再ADD。
解决1022的三种常用方案与代码示例
最直接的修复方式是在建表语句里改用唯一外键名。以下示例展示两张表分别使用带表前缀的外键，避免1022：
CREATE TABLE `user` (
`id` INT PRIMARY KEY,
`name` VARCHAR(50)
) ENGINE=InnoDB;
CREATE TABLE `order` (
`id` INT PRIMARY KEY,
`user_id` INT,
CONSTRAINT `fk_order_user_id` FOREIGN KEY (`user_id`)
REFERENCES `user`(`id`)
) ENGINE=InnoDB;
CREATE TABLE `profile` (
`id` INT PRIMARY KEY,
`user_id` INT,
CONSTRAINT `fk_profile_user_id` FOREIGN KEY (`user_id`)
REFERENCES `user`(`id`)
) ENGINE=InnoDB;
如果表已经建立且外键名冲突，可以先删除旧外键再添加新名称。注意ALTER TABLE删除外键只认约束名，不认列名。示例如下：
ALTER TABLE `order` DROP FOREIGN KEY `fk_user_id`; ALTER TABLE `order` ADD CONSTRAINT `fk_order_user_id` FOREIGN KEY (`user_id`) REFERENCES `user`(`id`);
第三种方案适合批量导入场景：在导入SQL文件前，用sed或脚本把文件里固定的外键名替换为带随机后缀的字符串，或者在mysqldump时指定--skip-disable-keys并结合人工改名。这种办法对遗留系统迁移尤其有效，缺点是后期维护需记录改名规则。三种方式各有取舍，小项目推荐直接规范命名，大库迁移可用脚本批量改名。
预防MySQL 1022错误的工程化建议
从团队协作角度看，外键命名应当写入开发规范。建议采用“fk_从表_主表_列”的四段式，如fk_order_user_id，让任何成员看到名称就能知道关联双方。同时在持续集成环节加入SQL静态检查，扫描CREATE TABLE和ALTER TABLE语句中的CONSTRAINT字段，发现重复命名直接阻断合并。
另外，使用ORM框架时也要小心。部分框架在自动建表时会根据实体关系生成外键，若多个实体指向同一主实体且框架未加表前缀，同样会触发1022。可以在框架配置里开启外键名自定义策略，或者关闭自动外键改用手动迁移脚本。对于已上线的库，定期跑一次外键名查重脚本，能提前暴露命名隐患。
最后提醒，MySQL的1022与150错误不同，150是外键列类型不匹配，1022纯属名字冲突。分清二者可少走弯路。只要把外键当作全局资源来命名和管理，这类错误完全可以在设计阶段消灭。