Быстрее ли получить строку в MySQL, если первичным ключом является строка (varchar) или целое число?

Question

Я создаю базу данных для словаря.Рассмотрим таблицу WORD.Мой текущий план состоит в том, чтобы сделать его первичный ключ word_id, который будет целым числом, а затем присвоить ему другой атрибут text, который представляет собой текстовое представление слова.

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

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

Кроме того, если скорость не такая большая проблема, есть ли другие факторы, которые я должен учитывать?База данных, которую я собираюсь использовать, - MySQL.

Answer 1

Вы можете проверить этот вопрос:

Есть РЕАЛЬНАЯ разница в производительности между первичными ключами INT и VARCHAR?

Я думаю, что это охватывает ваш вопрос.

Answer 2

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

Answer 3

Еще один момент, который стоит в пользу int, заключается в том, что строки приводят к следующим вопросам:

1. Чувствителен ли регистр сравнения?

2. Обрезан ли текст или в нем есть дополнительные невидимые пробелы?

3. Правильно ли закодировано?(Это может быть проблемой, если данные импортируются / экспортируются из / в другую систему.)

4. Значимые ключи могут быть отредактированы, в то время как никто не может редактировать столбец идентификации, и никто не заинтересован вредактирование guid или бессмысленного int.

Answer 4

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

Я предполагаю, что вы правы, но разница настолько мала по сравнению с другими задачами обработки (например, сеть + дисковый ввод / вывод) сервером базы данных, что это не имеет значения.