текстовые индексы против целочисленных индексов в MySQL

Question

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

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

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

Ура, imanc

Answer 1

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

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

• Производительность (как сказал Коронат)

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

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

Answer 2

При сравнении чисел компьютеры работают НАМНОГО быстрее, чем строки.

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

Если у вас есть строки blabfoo, blabbar, blabboo, индекс будет полностью бесполезен, потому что первые 4 символа равны, поэтому поиск «blabf» будет изначально совпадать со ВСЕМИ 3 строками, а затем итерировать результаты.

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