MySQL外鍵自動生成的名稱是否確定？

Question

創建約束時，它們的名稱類似於“FK5E6B788655A1514E”。

我想知道名字生成是確定性的還是隨機的。 我注意到我使用的兩個獨立的數據庫，相同的模式，最終得到了相同的FK名稱。

將升級腳本從一個版本的模式編寫到另一個版本以使用這些約束名稱時是否有意義？

Answer 1

很長一段時間以來，我一直在想這個問題，在做了一些自己的研究之后，今天偶然發現了你的帖子。 希望我發現的將幫助你。

來自http://dev.mysql.com/doc/refman/5.5/en/innodb-adaptive-hash.html ：

InnoDB有一種監控索引搜索的機制。 如果InnoDB注意到查詢可以從構建哈希索引中受益，那么它會自動執行。 此功能由innodb_adaptive_hash_index選項啟用，或在服務器啟動時由--skip-innodb_adaptive_hash_index關閉。

此處說明了實現此功能的原因：

如果表幾乎完全適合主內存，則哈希索引可以通過啟用任何元素的直接查找來加速查詢，將索引值轉換為一種指針。

有關adaptive_hash_index的更多信息，請訪問： http ： //dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_adaptive_hash_index

在那里，他們解釋了索引名稱的實際生成：

哈希索引始終基於現有的InnoDB二級索引構建，該索引被組織為B樹結構。 MySQL可以在為B樹定義的任意長度的密鑰的前綴上構建哈希索引，具體取決於針對索引的搜索模式。 哈希索引可以是部分的; 整個B樹索引不需要緩存在緩沖池中。

最后，這里有更多的索引： http ： //dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html

閱讀完所有這些內容后，我相信只要您的數據庫模式和引擎相同並且在不同的環境中具有相同的配置選項，您就可以在進化/遷移腳本中使用這些值。

Answer 2

似乎機器生成的名稱是一致的。 但這不是保證行為。 我懷疑如果MySQL在某些未來版本中需要更改生成名稱的方法，他們就不會覺得這樣做會破壞向后兼容性。

您是否知道自己可以指定約束名稱，以繞過自動生成的名稱？

create table foo (
  i int, 
  constraint `i_is_unique` unique key (i)
);