интервьюер:Я вижу, что в вашем резюме написано MySQL.Вы знаете что-нибудь об индексах движка MySQL InnoDB?
Кандидат: Ну, использование индекса может ускорить скорость запроса, по сути, это превратить неупорядоченные данные в порядок (упорядочение может ускорить скорость поиска)
Кандидат: В движке InnoDB базовая структура данных индекса представляет собой дерево B+.
интервьюер:Так почему бы не использовать красно-черное дерево или B-дерево?
Кандидат: данные MySQL хранятся на жестком диске, как правило, невозможно загрузить все данные в память "за один раз" при запросе
Кандидат: красно-черное дерево — это вариант «бинарного дерева поиска», узел узла может хранить только один ключ и одно значение.
Кандидат: деревья B и B+ отличаются от красно-черных деревьев. Они считаются «многосторонними деревьями поиска». По сравнению с «бинарными деревьями поиска» узел узла может хранить больше информации. «Многосторонние деревья поиска» Высота будет быть ниже «бинарного дерева поиска».
Кандидат: Поняв разницу, на самом деле очень легко обнаружить, что в сценарии, когда данные не могут быть загружены в память за один раз, данные необходимо извлечь, и причина для выбора дерева B или B+ вполне достаточна. (узел Node хранит больше информации (соответственно). По сравнению с бинарным деревом поиска) высота дерева ниже, а высота дерева влияет на скорость поиска)
Кандидат: По сравнению с деревом B дерево B+ имеет две характеристики.
Кандидат: 1. Нелистовые узлы дерева B+ не хранят данные.При одинаковом количестве данных дерево B+ короче и прочнее. (Это не требует дополнительных объяснений, данные хранятся на листовых узлах, а хранилище нелистовых узлов может хранить больше индексов, поэтому все дерево короче и прочнее)
Кандидат: 2. Между дочерними узлами дерева B+ формируется связный список, что удобно для обходных запросов (операции обхода чаще встречаются в MySQL)
Кандидат: Позвольте мне немного объяснить, вы можете составить картину
Кандидат: В движке MySQL InnoDB каждый раз, когда мы создаем индекс, это эквивалентно созданию дерева B+.
Кандидат: Если индекс является «кластеризованным (кластеризованным) индексом», конечные узлы текущего дерева B+ хранят «первичный ключ и данные текущей строки».
Кандидат: если индекс является «некластеризованным индексом», конечный узел текущего дерева B+ хранит «первичный ключ и текущее значение столбца индекса».
Кандидат: Например, если вы пишете sql: выберите * от пользователя, где идентификатор >= 10, если вы найдете запись с идентификатором 10, а затем пройдете связанный список (связанный список, состоящий из конечных узлов) между листовые узлы, вы можете найти следующий записанный.
Кандидат: поскольку B-дерево также хранит данные в неконечных узлах, возможно, их придется извлекать между слоями при обходе, что относительно проблематично.
Кандидат: исходя из уровня дерева и характеристик сценария использования в бизнесе, MySQL выбрала дерево B+ в качестве базовой структуры данных индекса.
Кандидат: Для хеш-структуры движок InnoDB фактически является «адаптивным» хэш-индексом (создание хэш-индекса автоматически оптимизируется и создается движком хранилища InnoDB, мы не можем вмешиваться)
интервьюер:В порядке...Тогда я понимаю, кстати, вы знаете, что такое форма возврата?
Кандидат: Так называемая таблица возврата на самом деле заключается в том, что когда мы используем индекс для запроса данных, извлеченные данные могут содержать другие столбцы, но дочерний узел дерева индекса может найти только текущее значение столбца и идентификатор первичного ключа, поэтому мы нужно перейти к идентификатору первичного ключа. Проверьте данные, чтобы получить столбцы, требуемые SQL
Кандидат: Например, я построил индекс для идентификатора заказа, но мой SQL таков: выберите orderId, orderName from orderdetail, где orderId = 123
Кандидат: SQL индексирует все идентификаторы заказов, но в листовых узлах дерева индексов идентификаторов заказов есть только orderId и Id, и мы также хотим получить orderName, поэтому MySQL получит идентификатор, а затем узнает orderName и вернет его в нам. Эта операция называется формой возврата
Кандидат: Если вы хотите избежать возврата к таблице, вы также можете использовать покрывающий индекс (используйте его, если можете, потому что операция возврата таблицы исключена).
Кандидат: так называемый покрывающий индекс на самом деле означает, что столбцы, которые вы хотите узнать, существуют на листовых узлах. Например, я построил совместный индекс orderId и orderName, и мне просто нужно запросить orderId и orderName. Эти данные все они существуют в дереве индексов.На листовых узлах нет необходимости возвращаться к таблице.
интервьюер:Поскольку вы также упомянули совместное индексирование, я хотел бы спросить, понимаете ли вы принцип самого левого сопоставления?
Кандидат: Ну, чтобы проиллюстрировать эту концепцию, проще объяснить на примере.
Кандидат: если есть индекс (a,b,c,d) и условия запроса a=1 и b=2 и c>3 и d=4, то a, b и c будут найдены последовательно в каждом узле. , но d нельзя поразить
Кандидат: Сопоставление самого левого сначала, индекс может использоваться только для определения того, существует ли ключ (равно), и его нельзя сопоставить при обнаружении запросов диапазона (>,
Кандидат: это самый левый принцип сопоставления
интервьюер:Хм, я также хочу спросить, как генерируется ваш первичный ключ?
Кандидат: первичный ключ автоматически увеличивается
интервьюер:Итак, если я не буду использовать первичный ключ с самоинкрементом MySQL, в чем, по-вашему, будет проблема?
Кандидат: Прежде всего, первичный ключ должен гарантировать, что он уникален, а пространство должно быть как можно короче Эти две части необходимо учитывать.
Кандидат: Кроме того, из-за характеристик индекса (упорядоченный), если генерируется первичный ключ, такой как uuid, производительность вставки хуже, чем у автоинкремента.
Кандидат: Из-за сгенерированного uuid может возникнуть необходимость переместить блок диска при вставке (например, место в блоке в текущий момент заполнено, но вновь сгенерированный uuid нужно вставить в полный блок, а данные блока нужно переместить)
интервьюер: В ПОРЯДКЕ...
Резюме этой статьи:
- Почему деревья B+? Данные не могут быть загружены в память за один раз.Дерево B+ является многосторонним деревом поиска.Только листовые узлы хранят данные, а связанные списки между листовыми узлами связаны. (Дерево короткое, легко обходимое)
- Что такое форма возврата? Некластеризованные индексы хранят только значения столбцов и идентификаторы первичных ключей в листовых узлах.По возможности следует использовать покрывающие индексы, чтобы избежать операций возврата к таблице и повысить скорость запросов.
- Что такое самый левый принцип соответствия? Продолжайте сопоставление с крайней левой начальной точки и заканчивайте, когда встречается запрос диапазона
- В чем проблема с несамоувеличивающимся первичным ключом?? Эффективность вставки снижается, и возникает проблема с данными при перемещении блоков.
Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим об интервью по Java
Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!
【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!
Оригинал это не просто! ! Проси три! !