Преимущество BTREE?

Question

Я создаю индексы без предложения «USING BTREE». Есть ли преимущество использования индекса BTREE?

CREATE INDEX `SomeName` USING BTREE ON `tbl_Name`(`column_name`); 

Answer 1

BTREE - это метод индекса по умолчанию. Вы можете спокойно его опустить.

Answer 2

Это зависит от того, какой механизм хранения вы используете. Для большинства, BTREE является значением по умолчанию, поэтому его указание ничего не меняет. Для систем хранения, таких как MEMORY/HEAP и NDB, по умолчанию используется индекс HASH по умолчанию.

Более подробную информацию можно найти here.

ли или нет B-дерево или индекс HASH выгодно для вас с точки зрения производительности зависит от данных, и как вы к нему доступ. Если вы знаете, что ваши запросы будут нацелены только на одну строку или отдельные отдельные строки, то индекс HASH может оказаться полезным. Что-то еще, кроме этого, я обычно предпочитаю индекс BTREE по мере сортировки данных и, таким образом, делает запросы диапазона и те, которые возвращают многострочные более эффективные.

Answer 3

Прежде всего, в зависимости от используемого механизма хранения, у вас может не быть выбора (например, InnoDB использует исключительно BTREE для своего индекса).

Кроме того, BTREE является стандартным типом индекса для большинства систем хранения.

Теперь ... Есть случаи, когда использование альтернативных типов индексов может привести к повышению производительности. Есть (относительно редкий случай), когда индекс HASH может помочь. Обратите внимание, что при создании индекса HASH создается также индекс BTREE. Частично это связано с тем, что хэш-индексы могут разрешать только предикаты равенства. (условие, такое как WHERE Price> 12.0, не может быть обработано хэш-индексом).

Вкратце: продолжайте использовать BTREE, неявно (если BTREE является значением по умолчанию для используемого хранилища) или явно. Узнайте о других типах индексов, чтобы вы знали о них, возникла бы необходимость.

Edit: (в поиске случаев, когда могут быть использованы альтернативные типы индексов)
Эффективно дело довольно прямо вперед для RTREE индексов. Они поддерживаются только с MySQL в контексте "SPATIAL" databases, то есть базы данных, которые включают в себя контекст геоданных, например Point и другой объект в модели GIS).

Индексы HASH являются более универсальными (не ограничиваясь конкретным приложением или типом данных), и обычно можно следовать интуитивному пониманию хешей, чтобы получить подсказку о том, когда они могут превзойти старые, но верные БРИТ. Как указывалось ранее, это подразумевало бы, что столбцы обычно просматриваются с равным предикатом. Я предполагаю, что относительно короткие таблицы поиска и тому подобное могут быть полезны, в зависимости от эффективной реализации в MySQL.

Answer 4

Поиск сбалансированного дерева означает, что все листья находятся на одной и той же глубине. Накладные расходы на ВПП отсутствуют. Действительно, даже большие B-деревья могут гарантировать, что небольшое количество узлов должно быть восстановлено, чтобы найти данный ключ. Например, B-дерево из 10 000 000 ключей с 50 ключами на узел никогда не должно извлекать более 4 узлов, чтобы найти какой-либо ключ. B-tree - это специальный формат структуры данных для индекса, который позволяет быстро получить доступ к данным в индексе. Один из свойств этой структуры данных состоит в том, что индекс всегда балансирует. Это означает, что каждый узел на самом низком уровне является эквидистантным от самого верхнего узла или корневого узла дерева. И каждая сторона индекса имеет такое же количество узлов. Узлы на самых низких уровнях известны как листовые узлы. Все остальные узлы известны как узлы ветвей. к другим ветвям или узлам листа.Листовые узлы хранят значения индексированных столбцов и rowid, которые указывают на отдельную строку, которая имеет эти значения. Фактическое распределение будет зависеть от количества значений данных в каждом диапазоне значений в B-дереве с общей целью сократить количество требуемых уровней, которые необходимо пройти, чтобы получить конкретное значение. Преимущество структуры B-дерева:

1. Все листовые блоки имеют одинаковую глубину (количество значений).
2. Высота B-дерева обычно довольно маленькая. В некоторых случаях корневой узел является единственным листовым узлом, а высота равна 1. Так как в таблицы добавлено больше строк, индекс должен расти, чтобы соответствовать этому . Но даже в таблицах с более чем 1 миллионом строк, идеал B-дерева обычно имеет высоту 3. В самой большой таблице высота может быть только 4. Это означает, что для даже самых больших таблиц она занимает всего 4 блока чтобы найти rowid строки, которую вы ищете, это чрезвычайно эффективно.
3. В случае случайных введенных данных, B-дерево сохраняет баланс автоматически. Фактически, B-дерево остается в балансе независимо от того, какие данные вводятся в него.
4. Все блоки индекса B-дерева заполнены в три четверти (в среднем), что позволяет вставить без rebulid. 5.B-дерево обеспечивает отличную производительность для всех типов выборок. 6. Вставка, обновление и удаление имеют тенденцию быть эффективными в структуре B-дерева. Эффективность 7.B-дерева остается оптимальной, даже если таблицы от малого до большого.

Answer 5

Упрощенный ответ: если ваш SQL использует оператор LIKE в этом поле, то использование индекса BTREE должно превышать индекс хеша. Если вы используете равные (=) утверждения в отношении этого поля, используйте Hash Index.