#mysql #performance #unique-key
#mysql #Производительность #уникальный ключ
Вопрос:
В таблице 1 есть 3 столбца: id (автоинкрементный), citynumber (уникальный), description (varchar(1000)). Идентификатор столбца никогда не используется в запросах. Он используется просто для моего удобства (чтобы увидеть, как растет таблица, проще ссылаться на id, чем на citynumber, хотя id никогда не используется при выполнении sql-запросов).
Вы бы настоятельно рекомендовали удалить столбец id для повышения производительности?
Ответ №1:
Удаление столбца id не увеличит производительность или, по крайней мере, не будет разумным способом. Вы можете сохранить только тот же диск. Кроме того, преимущества, которые может дать вам PK, обычно намного лучше, чем экономия места.
Ответ №2:
я знаю, что это вопрос для обсуждения, и в целом я считаю, что лучше всего сохранять индексы в таблицах, даже если они являются таблицами просмотра. просто мое мнение после работы с устаревшим кодом и таблицами базы данных, в которых нет индексов, которые понадобятся позже. да, это незначительное обновление, но базе данных все равно необходимо соответствующим образом переиндексировать все, что может повлиять на производительность во время этого обновления.
просто мое мнение.
Ответ №3:
Нет, столбцы ID почти всегда есть. Если вы когда-либо добавляли больше таблиц и хотели присоединиться к ним, столбец ID пригодится. Это вообще не должно влиять на производительность, а разница в потреблении пространства незначительна.
Ответ №4:
производительность будет зависеть от ваших запросов. действительно ли citynumber уникален (это естественный ключ?) тогда добавление индекса к этому столбцу значительно поможет, если это то, к чему вы присоединяетесь или фильтруете.
Ответ №5:
Предполагая, что вы храните в своей базе данных только реальные (не вымышленные) города, вы можете легко хранить все города мира, вообще не беспокоясь о производительности — набор данных слишком мал.
Ответ №6:
В InnoDB PK работает быстрее, чем уникальный индекс, потому что PK указывает на данные, а Unique указывает на PK и только после этого — на данные.
Итак, удалите id и сделайте citynumber первичным ключом.
Тем не менее, это не даст вам большого улучшения производительности.
Комментарии:
1. соглашаясь с вашей точкой зрения на «уникальные» ограничения в сравнении с PKS, я не вижу причин удалять столбец «id». полезны аналоги суррогатных ключей, аналогичные естественным ключам. даже если предложение where соответствует столбцу citynumber, объединения все равно могут быть связаны с суррогатным PK
2. Почему вы используете объединения против surogate PK? Насколько я понимаю из сообщения, тип данных id и citynumber могут совпадать.
3. может быть. в своем ответе я спросил, является ли номер города естественным ключом, но ответа не получил. что касается того, зачем присоединяться к суррогату, я бы ответил, что для этого они и существуют. по определению они существуют только для целей db и не должны иметь внешнего значения.