В MySQL тип индекса является b-деревом, а доступ к элементу в b-дереве выполняется в логарифмическом арифметическом времени O(log(n)).
С другой стороны, доступ к элементу в хэш-таблице находится в O(1).
Почему хеш-таблица не используется вместо b-дерева для доступа к данным внутри базы данных?
Вы можете обращаться к элементам только по их первичному ключу в хеш-таблице.
Это быстрее, чем с помощью алгоритма дерева (O(1) вместо log(n)), но вы не можете выбирать диапазоны (все между x и y).
Алгоритмы дерева поддерживают это в log(n), где в качестве хеш-индекса может быть выполнено полное сканирование таблицы O(n).
Также постоянные накладные расходы хэш-индексов обычно больше (что не является фактором в обозначениях тета, но оно все еще существует).
Кроме того, алгоритмы дерева обычно легче поддерживать, расти с данными, масштабами и т.д.
Индексы хэша работают с заранее определенными размерами хэша, поэтому вы получаете некоторые "ведра", в которых хранятся объекты. Эти объекты снова зацикливаются, чтобы действительно найти правильный внутри этого раздела.
Итак, если у вас небольшие размеры, у вас много накладных расходов для небольших элементов, большие размеры приводят к дальнейшему сканированию.
Современные алгоритмы хеш-таблиц обычно масштабируются, но масштабирование может быть неэффективным.
Существуют действительно масштабируемые алгоритмы хеширования. Не спрашивайте меня, как это работает - это тоже для меня. AFAIK они эволюционировали от масштабируемой репликации, где повторное хеширование непросто.
Его называют RUSH - R. <, и эти алгоритмы называются алгоритмами RUSH.
Однако может быть точка, в которой ваш индекс превышает допустимый размер по сравнению с вашими размерами хэша, и весь ваш индекс необходимо перестроить. Обычно это не проблема, но для огромных огромных баз данных это может занять несколько дней.
Компиляция для алгоритмов дерева небольшая, и они подходят практически для каждого варианта использования и, следовательно, по умолчанию.
Однако, если у вас очень точный вариант использования, и вы точно знаете, что и только что понадобится, вы можете воспользоваться индексами хеширования.
На самом деле, похоже, что MySQL использует оба типа индексов либо хеш-таблицу, либо b-дерево в соответствии со следующей ссылкой .
Разница между использованием b-дерева и хэш-таблицы заключается в том, что первая позволяет использовать сопоставление столбцов в выражениях, которые используют =, > , > =, <, <= =, или BETWEEN, а последний используется только для сравнений сравнений, которые используют операторы = или <= > .
Поскольку btree можно легко выгружать на диск. Кроме того, временная сложность хэш-таблиц постоянна только для достаточно больших хэш-таблиц (для хранения данных должно быть достаточно ведер). Размер таблицы базы данных не известен заранее, поэтому таблица должна быть перефразирована сейчас и затем, чтобы получить оптимальную производительность из хеш-таблицы. Переоборудование также дорого.
Я думаю, что Hashmaps также не масштабируются и могут быть дорогими, когда нужно перерисовать всю карту.