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) 
);