数据库
首页 > 数据库> > MySQL外键自动生成的名称是否具有确定性?

MySQL外键自动生成的名称是否具有确定性?

作者:互联网

创建约束后,它们会获得类似于“ FK5E6B788655A1514E”的名称.

我想知道名称生成是确定性的还是随机的.
我注意到,我正在使用的两个单独的数据库,具有相同的架构,最终都具有相同的FK名称.

将升级脚本从模式的一个版本编写到另一个版本以使用这些约束名称时,这有意义吗?

解决方法:

我一直想知道这个问题已经有一段时间了,今天在做一些自己的研究后偶然发现了您的帖子.希望我发现的内容能对您有所帮助.

http://dev.mysql.com/doc/refman/5.5/en/innodb-adaptive-hash.html开始:

InnoDB has a mechanism that monitors index searches. If InnoDB notices
that queries could benefit from building a hash index, it does so
automatically. This feature is enabled by the
innodb_adaptive_hash_index option, or turned off by the
–skip-innodb_adaptive_hash_index at server startup.

在此解释实现此功能的原因:

If a table fits almost entirely in main memory, a hash index can speed
up queries by enabling direct lookup of any element, turning the index
value into a sort of pointer.

有关adaptive_hash_index的更多信息,请参见:http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_adaptive_hash_index

在其中,他们解释了索引名称的实际生成:

The hash index is always built based on an existing InnoDB secondary
index, which is organized as a B-tree structure. MySQL can build a
hash index on a prefix of any length of the key defined for the
B-tree, depending on the pattern of searches against the index. A hash
index can be partial; the whole B-tree index does not need to be
cached in the buffer pool.

最后,这里还有更多索引:http://dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html

阅读完所有这些内容后,我相信,只要您的数据库模式和引擎相同,并且在不同环境上具有相同的配置选项,就可以在Evolution / migration脚本中使用这些值.

标签:foreign-keys,sql,mysql
来源: https://codeday.me/bug/20191107/2002824.html