предисловие

Текст был включен в мой репозиторий GitHub, добро пожаловать, звезда:GitHub.com/bin39232820…
Лучшее время посадить дерево было десять лет назад, затем сейчас
Я знаю, что многие люди не играютqqТеперь, но с ностальгией, добро пожаловать в группу Six Meridian Excalibur по изучению Java для новичков, номер группового чата:549684836Поощряйте всех вести блог на пути к технологиям

болтовня

Продолжим изучение mysql. Ранее мы узнали некоторые базовые знания об индексе mysql, сегодня мы подошли к индексу дерева Kangkang B+.

• 🔥Mysql от начала до увлечения (1) Оптимизация типа данных схемы и основа индекса
• 🔥Mysql от входа до увлечения (2) Процесс выполнения Select and Update
• 🔥Mysql от входа до восхищения (3) Структура хранения InnoDB

Давайте вчера рассмотрим структуру хранения страниц InnoDB. Мы знаем, что несколько разных страниц образуют двусвязный список, а строки данных на каждой странице образуют односвязный список в соответствии с размером первичного ключа, и каждые 4–8 данных чтобы сформировать слот, каждый слот хранится в pageDirectoy, когда мы хотим запросить данные строки страницы, мы можем сначала найти страницу, затем найти слот с помощью 2-точечного метода, а затем пройти слот, чтобы найти данные текущей строки. (Картинка, нарисованная здоровяком, всем понятно)

Страница a, страница b, страница c ... страница n Эти страницы могут быть не связаны в физической структуре, если они связаны через двусвязный список.

Нет возможности найти данные по индексу

• Первый - запросить определенное значение первичного ключа id. Это не кажется таким уж сложным. Во-первых, пройтись по всем страницам, найти страницу, найти слот на странице и найти текущую строку из слота Таким образом, таким образом, если количество страниц велико, запрос будет очень медленным.
• Второе - это полное сканирование таблицы, которое мы называем, пересекающие один за другим и, наконец, нахожу эту строку данных, потому что этот вид запроса будет очень медленным, поэтому наш индекс пригодится

Схемы индексации в InnoDB

• InnoDB использует страницы в качестве основной единицы для управления пространством для хранения, то есть может гарантировать до 16 КБ непрерывного пространства для хранения.С увеличением количества записей в таблице требуется очень большое непрерывное пространство для хранения всех данных. элементы каталога. , что нереально для таблиц с очень большим количеством записей.
• Мы часто добавляем или удаляем записи. Предположим, мы удаляем все записи на странице, и страница не должна существовать, что означает, что запись каталога не должна существовать, что требует каталога после записи каталога. Элементы все двинемся вперед, такой дизайн, который тянет за волосы и двигает всем телом, не очень хорошая идея~

Как это реализовано, записи страниц и записи пользователей, у него есть тип_записи в каждой строке данных, который может представлять как записи страниц, так и записи пользователей. Он имеет следующие 4 значения

• 0: обычная запись пользователя
• 1: Запись записи каталога
• 2: Минимальная запись
• 3: Максимальное количество записей

Будь то страницы данных, которые хранят записи пользователей, или страницы данных, которые хранят записи записей каталогов, мы храним их в структуре данных дерева B+, поэтому мы также называем эти страницы данных узлами. Как видно из рисунка, наши фактические пользовательские записи фактически хранятся на нижнем узле дерева B+.Эти узлы также называются листовыми узлами или листовыми узлами, а остальные узлы, используемые для хранения элементов каталога, называются не- листовые узлы или внутренний узел, где верхний узел дерева B+ также называется корневым узлом.

кластеризованный индекс

Приведенное выше число B+ само по себе является индексом первичного ключа. Мы также называем его кластерным индексом. Он имеет две характеристики.

• Используйте размер значения первичного ключа записи для сортировки записей и страниц, который включает три значения:

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

• Листовые узлы дерева B+ хранят полные записи пользователей. Так называемая полная пользовательская запись означает, что все значения столбца (включая скрытые столбцы) хранятся в этой записи.

Мы называем дерево B+ с этими двумя характеристиками кластерным индексом, и все полные пользовательские записи хранятся в листовых узлах этого кластерного индекса. Этот тип кластеризованного индекса не требует от нас явного использования оператора INDEX для его создания в операторе MySQL (операторы, связанные с индексом, будут представлены позже), механизм хранения InnoDB автоматически создаст для нас кластеризованный индекс. Еще один интересный момент заключается в том, что в механизме хранения InnoDB кластеризованный индекс — это способ хранения данных (все пользовательские записи хранятся в листовых узлах), то есть так называемый индекс — это данные, а данные — это индекс.

вторичный индекс

Все обнаружили, что представленный выше кластерный индекс может работать только тогда, когда условием поиска является значение первичного ключа, потому что данные в дереве B+ сортируются в соответствии с первичным ключом. Так что, если мы хотим использовать другие столбцы в качестве критериев поиска? Можно ли только последовательно проходить записи по связанному списку от начала до конца?

Нет, мы можем построить еще несколько B+-деревьев, и данные в разных B+-деревьях используют разные правила сортировки. Например, мы используем размер столбца c2 в качестве правила сортировки страницы данных и записей на странице, а затем строим дерево B+, эффект показан на следующем рисунке:

По сути, это почти то же самое, что и выше, а это означает, что дочерний узел хранит данные нашего индексного столбца + наш первичный ключ. Если нам нужны все данные в текущей строке, нам нужно выполнить операцию возврата таблицы.

совместный указатель

Мы также можем использовать размер нескольких столбцов в качестве правила сортировки одновременно, то есть строить индексы для нескольких столбцов одновременно, например, мы хотим отсортировать дерево B+ в соответствии с размером c2 и столбцы c3, который содержит два значения:

• Сначала отсортируйте каждую запись и страницу по столбцу c2.
• В случае, если столбец c2 записи совпадает, для сортировки используется столбец c3.

Аналогично этому, сначала индексируется первый столбец, а затем упорядочивается второй столбец, который должен располагаться по порядку, поэтому префиксный индекс, который мы вызываем, выглядит так.

стоимость индексации

После ознакомления с принципом индекса дерева B + тема этой статьи заключается в том, как лучше использовать индекс, хотя индекс — это хорошо, его нельзя построить, вы должны научиться его использовать, прежде чем использовать индекс. Цена игры, она будет тянуть ноги и время:

• стоимость места

  • Это очевидно. Каждый раз, когда создается индекс, для него должно быть построено дерево B+. Каждый узел каждого дерева B+ является страницей данных. По умолчанию страница будет занимать 16 КБ дискового пространства. Большое дерево B+ состоит из множества страницы данных, которые занимают много места для хранения.

• стоимость во времени

  • Каждый раз, когда данные в таблице добавляются, удаляются или изменяются, каждый индекс дерева B+ необходимо изменять. И мы сказали, что узлы каждого слоя дерева B+ сортируются в соответствии со значением столбца индекса от меньшего к большему, чтобы сформировать двусвязный список. Будь то запись в листовом узле или запись во внутреннем узле (то есть запись пользователя или запись записи каталога), односвязный список формируется в соответствии со значением столбца индекса от малого до большой. Операции добавления, удаления и модификации могут нарушить порядок узлов и записей, поэтому подсистеме хранения требуется дополнительное время для выполнения некоторых операций, таких как сдвиг записей, разбиение страниц и повторное использование страниц, чтобы сохранить порядок узлов и записей. Если мы создадим много индексов, дерево B+, соответствующее каждому индексу, должно будет выполнять соответствующие операции обслуживания, не будет ли это тормозить производительность?

Принципы создания высокопроизводительных индексов

независимый столбец

Что это обозначает? То есть условие, стоящее за нашим where =, должно быть независимым столбцом, а не id+1, такого рода вычисления, поэтому есть принцип всегда помещать индексный столбец на сторону, которая более согласована.

индекс префикса

Например, строка очень длинная, и тогда вам нужно создать индекс для этого поля.Если первые несколько полей из них хорошо узнаваемы, рекомендуется создать префиксный индекс. Это может значительно сэкономить место в индексе

многоколоночный индекс

Распространенной ошибкой является создание индекса для каждого столбца, что неправильно, и порядок создания объединенного индекса заполняется случайным образом, что также неправильно. Если вы используете ключевое слово объяснения для просмотра информации о слиянии индексов, это означает, что ваш индекс можно оптимизировать.

Выберите подходящий порядок индекса

Предположим, у вас есть 2 столбца для построения составного индекса, тогда какое поле является столбцом составного индекса? Определенного стандарта для этого нет, но условие по умолчанию — если у вас небольшое количество полей, поставьте их максимально впереди, без учета условия группировки, такая ситуация действительно быстрее.

индекс покрытия

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

Попробуйте отсортировать по сканированию индекса

Если результатом типа в объяснении является индекс, это означает, что mysql использует сканирование индекса для сортировки,

неиспользуемый индекс

Если вы обнаружите, что некоторые индексы никогда не будут использоваться, рекомендуется их удалить.

Несколько случаев, которые нельзя использовать при сортировке в индексе

• ASC, SECH MIX Для сцен, используя совместный индекс для сортировки, нам требуется порядок сортировки столбца сортировки, является последовательным, то есть либо столбцы сортируются правилом ASC или правила сортировки DESC.
• Столбец индекса, используемый для несортировки в предложении WHERE

Суммировать

• Индексы не строятся только потому, что хотят быть построенными.Все ли имеет цену?Можно только сказать,что взвешиваются все за и против
• Некоторые распространенные сценарии индексации
  • Эквивалентный запрос
  • соответствует индексу слева от комбинированного индекса
  • Запрос диапазона, который соответствует индексу слева от составного индекса.
  • Сопоставление эквивалентности и запросов диапазона
  • Групповой запрос
  • Сортировать
• Некоторые примечания по индексации
  • Индексировать только искомые, сгруппированные, отсортированные столбцы
  • Индексируйте только столбцы с высокой идентификацией данных (например, пол, индексировать не рекомендуется)
  • Для строки столбца, если можно установить префиксный индекс, лучше всего установить префиксный индекс
  • Чтобы свести к минимуму разбиение страниц, лучше всего создать автоинкремент для первичного ключа.
  • удалить ненужные индексы
  • Если вы можете использовать покрывающий индекс, попробуйте использовать покрывающий индекс, чтобы уменьшить количество возвратов к таблице.

конец

Мы продолжим сражаться в следующей главе. Часть статьи взята изКак работает MySQL: понимание MySQL в корне,

ежедневные комплименты

Хорошо всем, вышеизложенное является полным содержанием этой статьи. Люди, которые могут видеть это здесь, всенастоящий порошок.

Творить нелегко. Ваша поддержка и признание — самая большая мотивация для моего творчества. Увидимся в следующей статье.

Six Meridians Excalibur | Text [Original] Если в этом блоге есть какие-то ошибки, прошу покритиковать и посоветовать, буду очень признателен!