Производительность MySQL уникального поля varchar vs unique bigint

Я работаю над приложением, которое будет использовать шестнадцатеричное значение в качестве бизнес-ключа (в дополнение к полю автоматического увеличения в качестве первичного ключа), аналогично идентификатору URL-адреса в Gmail. Я добавлю уникальное ограничение в столбец и изначально думал о сохранении значения как bigint, чтобы уйти от поиска в поле varchar, но задавался вопросом, нужно ли это, если поле уникально.

Внутренние соединения будут выполняться с использованием поля автоматического приращения, и шестнадцатеричное значение будет использоваться в предложении where для фильтрации.

В каком виде производительности можно было бы просто сохранить значение как varchar (x) или, возможно, char (x) над дополнительной работой при выполнении преобразования в и из шестнадцатеричного значения, чтобы сохранить значение как целое в базе данных? Стоит ли дополнительная сложность?

Я быстро проверил небольшое количество строк (50 тыс.) и имел аналогичные результаты поиска. Если проблема с большой производительностью будет линейной или экспоненциальной?

Я использую InnoDB как движок.

Ответ 1

Является ли ваш hex значением GUID? Хотя я часто беспокоился о производительности таких длинных позиций, как индексы, я обнаружил, что в современных базах данных разница в производительности даже на миллионах записей довольно незначительна.

Потенциально большая проблема - это память, которую потребляет индекс (например, 16 байт против 4 байта int), но на серверах, которые я контролирую, я могу выделить для этого. Пока индекс может быть в памяти, я обнаружил, что из других операций больше накладных расходов, что размер элемента индекса не создает заметной разницы.

В верхней части, если вы используете GUID, вы получаете независимость от сервера для созданных записей и большую гибкость при объединении данных на нескольких серверах (что меня волнует, так как наша система агрегирует данные из дочерних систем).

В этой статье есть график, который, похоже, подтверждает мои подозрения: Мифы, GUID и Autoincrement

Ответ 2

Значение hex генерируется из UUID (реализация Java); он хэширован и усечен до меньшей длины (вероятно, 16 символов). Алгоритм для которого все еще обсуждается (в настоящее время SHA). Преимущество, которое я вижу в хранении значения в шестнадцатеричном или целочисленном, состоит в том, что если нам нужно было увеличить размер (который я не вижу в этом приложении при 16 char), мы могли бы просто увеличить усеченную длину и оставить старые значения не опасаясь столкновения. Преобразование в целые значения не будет работать так хорошо для этого.

Причина усечения и просто использование GUID/UUID - это просто сделать URL и API (который там, где они будут использоваться) более дружественными.

Ответ 3

При прочих равных условиях сохранение меньших данных сделает его более быстрым. В основном потому, что это займет меньше места, поэтому меньше дискового ввода/вывода, меньше памяти, необходимой для хранения индекса и т.д. И т.д. 50 тыс. Строк недостаточно, чтобы заметить это, хотя...