текстовые индексы vs целочисленные индексы в mysql

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

предположим, у меня есть таблица продуктов, и каждый продукт имеет глобально уникальный номер SKU - это будет строка, скажем, 8-16 символов. Почему бы не сделать это ПК? Обычно я бы сделал это поле уникальным индексом, но затем имел бы автоматическое приращение поля int в качестве PK, поскольку я предполагал, что это будет быстрее, проще в обслуживании и позволит мне чтобы делать вещи, как получить последние 5 записей с легкостью.

но с точки зрения оптимизации, предполагая, что я буду только соответствовать полному текстовому полю, а затем выполнять текстовые запросы (например,%%), можете ли вы, ребята, придумать какие-либо причины не использовать текстовый первичный ключ, скорее всего, типа varchar()?

Ура, imanc

8
indexing mysql optimization

2 ответов

использование номера SKU в качестве первичного ключа имеет некоторый смысл. Вам понравится индексировать его, чтобы быстро выполнять поиск по SKU. А СКУ-это природные индекс.

однако он имеет некоторые штрафные санкции:

  • производительность (как обыкновенного сказал)

  • отсутствие гибкости конструкции. Если по какой-либо причине SKU перестанет быть глобально уникальным, вы будете вынуждены изменить не только структуру таблицы, но и все ваши запросы.

  • изменение SKU одного элемента заставит вас изменить все отношения в базе данных.

6

компьютеры намного быстрее сравнивают числа, чем строки.

кроме того, индексы MySQL строк по умолчанию содержат только первые 4 буквы.

Если у вас есть строки blabfoo, blabbar, blabboo, индекс будет совершенно бесполезен, потому что первые 4 символа равны, поэтому поиск "blabf" будет initally соответствовать всем 3 строкам, а затем повторять результаты.

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

-2