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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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