Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Что я смогла найти по ним:
- Первичный ключ не может иметь NULL, а уникальный может.
- Первичный ключ может быть только один на таблицу, уникальных множество.
- Первичный ключ нельзя переименовать, уникальному можно дать любое имя.
- В инноДБ первичный ключ цепляется ко всем остальным ключам дописывая себя в конец, уникальный такого не делает.
Если так взглянуть, то у первичного ключа много ограничений по сравнению с уникальным, да ещё и увеличивает индексы, особенно будет заметно чем больше их существует. Кроме последнего пункта (сложно представить его необходимость), в чём преимущество первичного ключа? Почему стоит использовать его, а не уникальный?
Неактивен
Для MyISAM можно использовать UNIQUE KEY. Для InnoDB первичный ключ определяет структуру таблицы в хранилище и если его нет, то он создается неявно (то есть невидимый и не связанный ни с одной из колонок).
Неактивен
rgbeast написал:
Для MyISAM можно использовать UNIQUE KEY. Для InnoDB первичный ключ определяет структуру таблицы в хранилище и если его нет, то он создается неявно (то есть невидимый и не связанный ни с одной из колонок).
Так а по какому алгоритму принимать в итоге решение использовать или нет?
Неактивен
Первый уникальный индекс делайте первичным. Если уникальных индексов не планировалось, а таблица InnoDB, то все равно создайте первичный ключ.
Неактивен
rgbeast написал:
Первый уникальный индекс делайте первичным. Если уникальных индексов не планировалось, а таблица InnoDB, то все равно создайте первичный ключ.
Ну вот примерно так у меня и было. НО! Мне сейчас для связей по внешним ключам, сменить статус некоторых ключей с первичных, на уникальные, так как в случае удаления связей, мне нужен стал NULL а не удаление. И так вышло, что некоторые таблицы остались без первичных ключей. Я правильно понимаю, что вы предлагаете, пройтись по ним и создать первичный всё равно? А если не один из готовых столбцов, не выдержат ограничения первичного ключа, мне что, создавать ещё один отдельный столбец?
Неактивен
Если не получается создать первичный ключ, то создавать дополнительный столбец не обязательно - InnoDB автоматически это сделает и будет тайно использовать.
Неактивен
rgbeast написал:
Если не получается создать первичный ключ, то создавать дополнительный столбец не обязательно - InnoDB автоматически это сделает и будет тайно использовать.
Прям как серый кардинал, этот инноДБ
Неактивен
Ещё наткнулась на один момент из этой же оперы.
Таблицы на ИнноДБ, цепляют в конец любого ключа в добавок первичный, верно?
А если первичный сам является составным, то цепляют его весь или только часть?
Если пихают весь, и это раздувает все ключи, имеет ли смысл составной первичный ключ переименовать в уникальный?
Ещё вопрос не совсем в тему, но с того же момента. Заспорили с коллегой по поводу очерёдности составного ключа. Я вижу логичным ставить в начало столбцы, которые имеют меньшее количество вариаций, а в конец, которые имеют большее количество вариаций. Коллега утверждает обратное - рассудите нас пожалуйста.
Неактивен
animegirl написал:
Таблицы на ИнноДБ, цепляют в конец любого ключа в добавок первичный, верно?
А если первичный сам является составным, то цепляют его весь или только часть?
Весь.
animegirl написал:
Если пихают весь, и это раздувает все ключи, имеет ли смысл составной первичный ключ переименовать в уникальный?
Может быть.
animegirl написал:
Ещё вопрос не совсем в тему, но с того же момента. Заспорили с коллегой по поводу очерёдности составного ключа. Я вижу логичным ставить в начало столбцы, которые имеют меньшее количество вариаций, а в конец, которые имеют большее количество вариаций. Коллега утверждает обратное - рассудите нас пожалуйста.
Обоснуйте свою позицию.
Неактивен
vasya написал:
Обоснуйте свою позицию.
Допустим различных вариаций
А - 10
В - 100
С - 1000
Записей 100.000.000, чисто для ровности подсчёта, количество записей для всех вариаций одинаково
Есть сводный ключ A,B,C
По моему пониманию механизма использования поиска по ключам, в данном подходе алгоритм сначала сравнивает по А, тем самым из 100.000.000 записей остается 10.000.000 записей, из оставшихся сравнивает по В, и их остаётся 100.000, в которых сравниваем по С. Итого перебираем 110.100.000 записей.
Если ключ будет С,В,А
То этот же алгоритм пойдёт так, сравнивая по С из 100.000.000 останется 100.000, после сравнения по В останется 1000 записей для сравнивания по А. Итоге проходим 100.101.000.
Спасибо за наводящий вопрос, я кажется сама ответила на свой. Конечно же если мои понимания работы движка правильны. Что хотелось бы узнать заранее, перед тем, как я начну в очередной раз ключи перекраивать XD
Неактивен
Ответили верно, а вот понимание работы движка ..
Давайте я вам на почту отправлю переведенное второе издание "оптимизации производительности" Зайцева? Там очень хорошее описание с иллюстрациями.
Неактивен
vasya написал:
Ответили верно, а вот понимание работы движка ..
Давайте я вам на почту отправлю переведенное второе издание "оптимизации производительности" Зайцева? Там очень хорошее описание с иллюстрациями.
Буду благодарна
e14e7222@opayq.com
Неактивен
Хотела изменить заголовок темы, и добавить вопрос, но не смогла (
Задумалась в добавок вопросом разницы между уникальным ключом и обычным ключом. Ну кроме фактора уникальности. Есть разница в скорости? Скажем, если я создаю дополнительный ключ для более быстрой работы выборки (если из таблицы тянется значение из колонки находящиеся в используемом ключе, к таблице даже не идёт обращение, насколько я помню). Есть у меня первичный ключ А,В , который кроме ускорения поиска действует ограничителем по уникальности этих двух столбцов. Но так как из таблицы при сравнение колонок А и В постоянно запрашивается лишь столбец С, а остальные столбцы это техническая информация, то я предполагаю, что имеет смысл сделать ключ ограничение А,В,С, чтобы значение С вытягивалось напрямую из ключа, без того, чтобы движок лез в таблицу. Просто добавлять С в первичный ключ нельзя, так как потеряется уникальность по значениям А,В ,а выносить А,В в уникальный для ограничения, а А,В,С пихать в первичный не вижу смысла, так как первичный всей гурьбой подвесится к уникальному в хвост. Отсюда вывод, что нужно просто добавить А,В,С отдельный ключом. По логике приложения, что он будет уникальным, что обыкновенным погоды не изменит, НО! будут ли какие-нибудь изменения в скорости выборки в зависимости от выбора?
Неактивен
Все верно, логично создать отдельный ключ (A,B,C). Уникальным он будет или нет, разница небольшая:
Уникальный - при INSERT/UPDATE это дополнительная проверка, но сам индекс может храниться чуть более компактно, так как листья содержат ссылку на запись, а не на массив из возможно нескольких записей.
Я бы создал обычный индекс для этой задачи, но будет интересно, если проведете исследование сравнения обычного индекса и уникального по скорость выборки и объему и напишете здесь.
Неактивен
rgbeast написал:
Все верно, логично создать отдельный ключ (A,B,C). Уникальным он будет или нет, разница небольшая:
Уникальный - при INSERT/UPDATE это дополнительная проверка, но сам индекс может храниться чуть более компактно, так как листья содержат ссылку на запись, а не на массив из возможно нескольких записей.
Я бы создал обычный индекс для этой задачи, но будет интересно, если проведете исследование сравнения обычного индекса и уникального по скорость выборки и объему и напишете здесь.
У меня там один INSERT/UPDATE/REMOVE на 1-10М SELECT´ов, имеет смысл на них вообще ориентироваться?
А зачем мне ссылка на запись? Я же описала, в моём случае, мне не интересна запись, мне интересно более быстро извлечение последнего столбца ключа. Но из того, что вы написали, предполагаю, что уникальному приходится выполнять на одно действие меньше. А так, как основное действие выборка, выходит уникальный ключ в теории даст небольшой % прироста.
Я всё ещё жду книгу обещанную, мэйл сверху не фэйк.
Неактивен
Отправил.
Неактивен
vasya написал:
Отправил.
Ничего не пришло (
Может спамфильтр порезал. Я сейчас сделала его менее агрессивным, можете ещё раз послать?
Неактивен
Повторил.
Неактивен
vasya написал:
Повторил.
Видимо я была права про фильтр, письмо дошло. Для почитать про теорию не плохая книга, но нету ли уже не русском третьего издания. Я его брала в библиотеке, у нас оно есть на английском (да, я его знаю плохо, но читать пыталась), нету ли уже перевода всё-таки?
Неактивен
Страниц: 1