2009-09-22 3 views
3

Когда создаются ограничения, им присваиваются имена, которые выглядят примерно так: «FK5E6B788655A1514E».Являются ли MySQL Foreign Key автогенерированными именами детерминированными?

Мне интересно, является ли генерация имени детерминированным или случайным. Я заметил, что две отдельные базы данных, которые я использовал, одни и те же схемы, оказались с теми же именами 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 вторичный индекс , который организован как структура B-дерева. MySQL может построить индекс хеширования на префиксе любой длины ключа, определенного для B-дерева , в зависимости от шаблона поиска по индексу. Хэш-код может быть частичным; весь индекс B-дерева не должен быть кэширован в буферном пуле.

Наконец, есть немного больше индексов здесь: http://dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html

Прочитав все это, я считаю, что до тех пор, пока ваша БД схемы и двигатели одинаковы и имеют одинаковые параметры конфигурации на в разных средах, вы должны быть в порядке, используя эти значения в сценарии эволюции/миграции.

1

Похоже, что машинные имена согласованы. Но это не гарантированное поведение. Я подозреваю, что если бы MySQL нуждался в изменении метода генерации имен в какой-то будущей версии, они бы не чувствовали, что они нарушают обратную совместимость, делая это.

Знаете ли вы, что вы можете указать имена ограничений сами, чтобы обойти автоматически сгенерированные имена?

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

Да, я знаю ... но! кроме обновления, я не прикасаюсь к схеме вручную ... Я разрешаю создавать таблицы автоматически при развертывании приложения JavaEE. – carrier

 Смежные вопросы

  • Нет связанных вопросов^_^