创建约束时,它们的名称类似于“FK5E6B788655A1514E”。
我想知道名字生成是确定性的还是随机的。 我注意到我使用的两个独立的数据库,相同的模式,最终都有相同的FK名称。
将升级脚本从一个版本的模式编写到另一个版本以使用这些约束名称时是否有意义?
答案 0 :(得分:3)
我一直在想这个问题很长一段时间,在做了我自己的一些研究之后,今天偶然发现了你的帖子。希望我发现的东西会帮助你。
来自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辅助版本构建 index,组织为B树结构。 MySQL可以构建一个 散列索引在为该定义的键的任意长度的前缀上 B树,取决于对索引的搜索模式。哈希 指数可以是部分的;整个B树索引不需要 缓存在缓冲池中。
最后,这里有更多关于索引的内容:http://dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html
阅读完所有内容后,我相信只要您的数据库模式和引擎相同并且在不同的环境中具有相同的配置选项,您就可以在进化/迁移脚本中使用这些值。 / p>
答案 1 :(得分:1)
机器生成的名称似乎是一致的。但这不是保证行为。我怀疑如果MySQL在某些未来版本中需要更改生成名称的方法,他们就不会觉得它们会破坏向后兼容性。
您是否知道自己可以指定约束名称,以绕过自动生成的名称?
create table foo (
i int,
constraint `i_is_unique` unique key (i)
);