Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток!
Поделитесь пожалуйста соображениями по сабжу.
Есть две таблицы, допустим, таблица талонов (request, ключевое поле id) и таблица, содержащая историю событий, происходящих с талонами (request_event), request_event содержит в себе поле request_id, которое связано вторичным ключом с полем id таблицы request.
По ходу работы часто составляются запросы, в которых эти две таблицы джоинятся on request.id = request_event.request_id.
Индекс по умолчанию - BTREE.
А в секретных материалах сказано, что индексы типа hash работают побыстрее, но по они не используются, если приходится выбирать по >= или <=, впрочем в данном случае (join табличек) это и не требуется.
Суть вопроса - какой тип индекса для такой связки лучше создать и почему? Если в более общем виде - в каких случаях какой индекс лучше выбирать?
В этом (Паша, если ты это читаешь, то сори за некроманию ) сказано, что регулировать тип создания индекса нельзя (кроме memory-табличек), но на mysql 5.1 на табличке типа myisam вполне создался hash index и explain на него (где выборка шла по прямому равенству) показал, что индекс создаётся.
Вот и пришла в голову мысль - а может быть стоит создавать hash-индексы во всех тех случаях, когда выборка будет идти по прямому равенству (таких ведь случаев много irl).
Неактивен
Теоретически HASH-индексы занимают меньше места и должны быстрее работать (при выборке с точным равенством).
Какая конкретно реализация в MyISAM в 5.1 нужно проверить: самые простые проверки - что он другого размера, чем BTREE на такой же таблице; тест производительности на большой таблице.
Нужно не забывать, что для сортировки они тоже не работают.
Неактивен
В документации не описана возможность HASH индексов для MyISAM таблиц: http://dev.mysql.com/doc/refman/5.5/en/ … index.html
Следует проверить индекс более внимательно - например, работает ли он для нечеткого равенства.
Неактивен
Более того, я подозреваю, что никто не пробовал использовать HASH в MySQL
на больших объемах данных. Он действительно быстрее: в случае хорошего выбора
хэширующей функции он дает O(1) (а в случае плохого выбора — O(n)). Дерево
же всегда дает O(ln(n)), но вся эта теория хорошо работает тогда, когда все стра-
ницы индекса одинаково быстро доступны, что в реальных условиях, очевидно, не
так: некоторые в ОЗУ, а некоторые на диске. В результате я совсем не уверен, что
disk-based HASH будет сильно быстрее дерева.
Неактивен
Ну то есть к тому идёт, что стоит оставить hash-индексы для memory-таблиц, а для myisam использовать "честные" btree?
Неактивен
deadka, тебе как топискстартеру нужно выяснить действительно ли такие индексы есть. Кроме того, что они формально создаются, нет никаких указаний в их пользу.
Неактивен
Ок, проведу тесты, приложу сюда.
Неактивен
deadka, Очень интересно. Потестируй и расскажи !
Неактивен
Да, складывается ощущение, что в таблицах типа MyISAM формально hash-индексы поддерживаются, но начинка у них - btree.
Создал две таблицы:
Отредактированно deadka (05.02.2012 02:47:34)
Неактивен
В innodb тоже создается HASH-индекс? Наверное в bugs написать стоит, так как это либо бага либо бага документации (если они хотят такое поведение для совместимости, то его нужно описать).
Неактивен
В innodb тоже создаются фальшивые HASH-индексы. Результаты explain-а те же самые.
Неактивен