咱们直接拆解你的问题来解答：

1. MySQL是否会实际创建PetId_Uniq这个UNIQUE索引？ #

答案是不会。

在InnoDB引擎（MySQL默认存储引擎）中，主键本身就自带两个核心特性：

• 唯一性约束：主键列的值必须唯一且非空
• 聚簇索引：数据行直接存储在主键索引的叶子节点中

当你尝试给已经是主键的PetId列创建唯一索引时，MySQL会识别到这个唯一索引的约束逻辑和主键完全重叠——两者都是强制PetId的唯一性，且没有额外列或不同排序规则。此时MySQL不会在磁盘上生成新的索引结构，只会在数据字典中记录这个索引的名称（避免执行CREATE UNIQUE INDEX时报错），但底层不会占用额外存储空间，也不会生成独立的索引文件。

你可以执行SHOW INDEX FROM Pet;查看，会看到PetId_Uniq的条目，但它的Seq_in_index、Cardinality等参数会和主键索引完全一致，本质上是指向同一个索引结构的“别名”。

2. 这个操作是否会带来性能差异？ #

几乎不会有任何性能差异。

因为没有实际创建新索引：

• 对于DML操作（INSERT/UPDATE/DELETE），不需要额外维护这个“假”索引，所以不会增加写入开销，性能和只有主键索引时完全一样。
• 对于查询操作，如果你在SQL中指定使用PetId_Uniq索引（比如FORCE INDEX(PetId_Uniq)），MySQL实际上会直接调用主键索引执行查询，执行计划和查询性能和使用主键索引没有区别。不过用EXPLAIN查看时，可能会显示使用PetId_Uniq，但这只是元数据层面的显示，底层逻辑完全一致。

不过要提醒一句：虽然不会有性能影响，但这种做法会造成元数据冗余，容易让维护人员误解数据库存在额外索引，增加不必要的排查成本，所以还是建议清理掉这类重复的索引定义。

内容的提问来源于stack exchange，提问作者steavy