Очистите познание, а затем заново поймите структуру индекса MySQL.

MySQL

предисловие

Привет, вот и я снова, это почти конец года, как начинающий фермер, я хочу сохранить себе итоги на конец года. Написано из предыдущего постаРучная сборка кластера Redis и синхронизации master-slave MySQL (без Docker)и предыдущая статьяПрактическая реализация разделения чтения и записи MySQL и аварийного переключенияПосле этого я просто поделился самым основным и самым сложным для понимания контентом в базе данных на этот раз, то есть индексом, и поделился им со всеми. В этом блоге я расскажу о своих взглядах на структуру индекса и поделюсь тем, как понять структуру индекса с нуля, слой за слоем.

Начните с простой таблицы

create table user(
	id int primary key,
    age int,
    height int,
    weight int,
    name varchar(32)
)engine = innoDb;

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

Во-первых, мы вставляем некоторые данные в эту таблицу.

INSERT INTO user(id,age,height,weight,name)VALUES(2,1,2,7,'小吉');
INSERT INTO user(id,age,height,weight,name)VALUES(5,2,1,8,'小尼');
INSERT INTO user(id,age,height,weight,name)VALUES(1,4,3,1,'小泰');
INSERT INTO user(id,age,height,weight,name)VALUES(4,1,5,2,'小美');
INSERT INTO user(id,age,height,weight,name)VALUES(3,5,6,7,'小蔡');

Давайте проверим, попали ли эти данные в таблицу.

select * from user;

最初的表

Как видите, данные полностью разместились в созданной нами пользовательской таблице.

ноЯ не знаю, нашли ли вы что-нибудь. Кажется, произошла очень странная вещь. Данные, которые мы вставили, похоже, не в порядке...

MySQL незаметно сортирует нас по идентификатору.

Почему MySQL молча сортирует нас без явной сортировки? Когда сортируется?

введение страницы

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

В концепции операционной системы, когда мы извлекаем данные с диска, предполагается, что размер извлекаемых данных составляет 1 КБ, но операционная система будет извлекать данные не только 1 КБ, но и данные 4 КБ, поскольку операционная система system Размер записи в таблице страниц составляет 4 КБ. Так почему же нам нужен только 1 КБ данных, а ОС должна получить 4 КБ данных? Это включает в себяместо программыПонятие , конкретное понятие не могу назвать, наверноеПосле того, как программа обращается к фрагменту данных, весьма вероятно, что она снова обратится к этому фрагменту данных и смежным с ним данным.", так что просто загрузите 4 КБ данных прямо в память, в следующий раз, когда вы захотите получить доступ к данным на этой странице, ищите их прямо из памяти, что может уменьшить количество дисковых операций ввода-вывода. Мы знаем, что дисковый ввод-вывод является основным фактор, влияющий на производительность программы, т.к. скорость дискового ввода-вывода и памяти неодинакова.

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

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

Прежде всего, мы должны начать чтение с данных с id=1, а затем судить, нужны ли они нам, если нет, то возьмем данные с id=2, а затем рассудим и повторим. Излишне говорить, что после того, как MySQL разберется с нами, мыНеобходимо пройти через пять дисковых операций ввода-вывода, чтобы найти и прочитать данные № 5.

Тогда давайте посмотримПосле введения концепции страниц, как мы читаем данные.

После введения концепции страницы MySQL будет хранить несколько фрагментов данных в структуре данных, называемой «страница».Когда MySQL читает данные с идентификатором = 1, он будет читать всю страницу страницы, на которой расположены данные с идентификатором = 1. в память, а затем пройти и судить в памяти.Поскольку скорость ввода-вывода памяти намного выше, чем у диска, она почти незначительна по сравнению с дисковым вводом-выводом, поэтому давайте посмотрим, сколько раз нам нужно пройти через дисковый ввод-вывод для чтения данных таким образом (при условии, что каждая страница может хранить 4 фрагмента данных). Затем мы впервые прочитаем данные с id=1 и прочитаем все данные с id=1 до id=4 в память,Это первый дисковый ввод-вывод, второй раз прочитает данные с id=5 в память,Это второй диск IO. такНам нужно всего лишь пройти через 2 дисковых ввода-вывода, чтобы найти эти данные с id=5..

Но на самом деле в движке MySQL InnoDb размер страницы составляет 16 КБ, что в 4 раза больше, чем у операционной системы, при этом данные типа int составляют 4 байта, а количество байт данных других типов обычно находится в пределах 4000 байт. , Таким образом, на странице может храниться очень много фрагментов данных, иДанные MySQL состоят из страниц в качестве базовой единицы..

最初的页结构

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

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

Влияние сортировки на производительность

Мы подняли вопрос выше,Почему база данных сортирует данные при вставке?? Разве не приятно, что мы вставляем данные в обычном порядке?

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

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

  • Процесс запроса на основе хранения в одностраничном режиме

    Или на основе карты страницы в нашем первом разделе мы вставили пять фрагментов данных, идентификаторы от 1 до 5, тогда предположим, что я хочу найти идентификатор, которого нет в таблице,Предположим, идентификатор = -1, то текущий процесс запроса:

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

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

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

Возможные проблемы с вышеуказанным режимом страницы

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

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

Знакомство с каталогом страниц

Мы можем провести аналогию: когда мы читаем книгу, если мы хотим найти определенный раздел, но мы не знаем, на какой странице находится этот раздел, должны ли мы переходить от начала к концу, раздел за разделом, чтобы найти что нам нужно?Что насчет номера страницы контента? Ответ - нет, потому что в начале книги естьсодержание, он сообщит вам, на какой странице находится раздел, например, первый раздел находится на странице 1, а второй раздел — на странице 13. На страницах БД фактически используется эта структура каталогов, т.е.каталог страниц.

Затем, после введения каталога страниц, структура страницы, которую мы понимаем, становится такой:

加了页目录的页结构

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

Затем сравните процесс поиска в базе данных, когда нет каталога страниц. Предположим, вы хотите найти данные с id = 3. В случае отсутствия каталога страниц вам нужно найти id = 1, id = 2, id = 3. , три раза, чтобы найти данные, если есть каталог страниц, вам нужно только проверить, какой элемент каталога с идентификатором = 3 существует, а затем напрямую искать данные через элемент каталога.Если данные не найдены в каталоге элемент, то вы можете напрямую определить, что эти данные не существуют, что значительно повышает эффективность поиска в базе данных, но реализация такого рода каталога страниц сначала должна основываться на сцене, где данные были отсортированы до это может сыграть свою роль, так что см. здесь, вы должны понять второй вопрос, почему база данных будет сортироваться при вставке,Вот где сортировка действительно вступает в игру.

расширение страницы

Выше мы в основном объяснили концепцию страниц в базе данных MySQL и то, как она уменьшает количество дисковых операций ввода-вывода на основе страниц и как сортировка оптимизирует эффективность запросов. Итак, давайте теперь подумаем о третьем вопросе: когда мы говорили о концепции страниц в начале, мы сказали, что размер каждой страницы в MySQL составляет всего 16 КБ, и она не будет автоматически расширяться при вставке данных, поэтому эти 16 КБ невозможно сохранить все наши данные, тогда должно быть несколько страниц для хранения данных,Итак, в случае нескольких страниц, как MySQL организует эти страницы??

В ответ на эту проблему, давайте продолжим рисовать схему многостраничной структуры, которую мы знаем сейчас:

多页结构

Видно, что в случае увеличения данных MySQL будет открывать новые страницы для хранения новых данных, и каждая страница имеет указатель на следующую страницу и указатель на предыдущую страницу. данные каждого столбца помещаются в область данных, гдеИдентификатор представителя перед первым пробелом), первая страница хранит данные с идентификатором 1-5, вторая страница хранит данные с идентификатором 6-10, а третья страница хранит данные с идентификатором 11-15.Следует отметить, чтоПри открытии новой страницы данные, которые мы вставляем, не обязательно помещаются на вновь открытую страницу, но нам необходимо сравнить данные всех страниц, чтобы определить, на какой странице размещаются вставленные данные., а после завершения ввода данных окончательныймногостраничная структураОн будет таким, как на картинке выше.

многостраничный режим

В многостраничном режиме MySQL может, наконец, завершить хранение нескольких данных, то есть путем открытия новой страницы, размещения нескольких фрагментов данных на разных страницах, а затем использования структуры данных связанного списка для соединения каждой страницы. Затем вы можете подумать о четвертом вопросе:Влияет ли это на эффективность запроса в случае нескольких страниц?

  • Влияние многостраничного режима на эффективность запросов

    В ответ на этот вопрос, поскольку он был задан, ответ положительный. Несколько страниц окажут определенное влияние на эффективность запросов. Влияние в основном отражается на:Суть многостраничного размещения также заключается в структуре связанного списка., пока это структура связанного списка, эффективность запроса не будет высокой. Предположим, что фрагментов данных слишком много, база данных откроет много новых страниц, и эти новые страницы будут связаны друг с другом, как связанный список.Когда мы хотим запросить определенный фрагмент данных на стольких страницах, он будет по-прежнему проходят от головного узла.На странице, где существует часть данных, которые мы ищем, нам удалось оптимизировать эффективность запроса данных на странице через каталог страницы, и теперь есть связанный список на основе страницы. Разве это не пустая трата всех предыдущих усилий?

  • Как оптимизировать многостраничный режим

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

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

    Итак, после анализа структура нашего многостраничного режима будет такой, как показано на следующем рисунке:

    形成B+树

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

    Здесь следует отметить следующее:Суть страницы каталога — это тоже страница, данные, хранящиеся на обычной странице, — это данные проекта, а данные, хранящиеся на странице каталога, — это адрес обычной страницы.

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

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

Внедрение дерева B+

Характеристики дерева B+, в котором я нахожусь "[От записи к записи] Базовый дизайн базы данных, из-за которой у людей выпадают волосы» подробно описано, поэтому повторяться здесь не буду.Если есть ученики, которые не понимают, можете зайти в этот блог.

Давайте поговорим дальше, мы будем рисовать многостраничную диаграмму шаблона существующей страницы каталога, которую мы рисуем, что может сформировать следующую картину:

多页宏观化

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

  • Преимущества деревьев B+

    1. Поскольку все данные хранятся на листовых узлах и связаны указателями, каждый листовой узел логически связан, поэтому поиск по диапазону более удобен.
    2. Все данные дерева B+ находятся на листовых узлах, поэтому эффективность запросов дерева B+ стабильна, и к нему обычно запрашивают три раза.
    3. Деревья B+ хороши для сканирования базы данных.
    4. Дерево B+ хорошо для дискового ввода-вывода, поскольку его высота слоя не будет увеличиваться из-за расширения данных (трехслойная древовидная структура может хранить около 20 миллионов томов данных.

Полная структура страницы

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

页结构

На рисунке выше показана структура данных страницы. Поле заголовка файла используется для записи информации заголовка страницы. Наиболее важными являются поля FIL_PAGE_PREV и FIL_PAGE_NEXT. Через эти два поля мы можем найти предыдущую страницу и следующую страницу. страницы.На самом деле все страницы могут формировать двусвязный список через два поля. Поле заголовка страницы используется для записи информации о состоянии страницы. Следующие Infimum и Supremum представляют собой две записи псевдострок, запись Infimum (infermum) меньше любого значения первичного ключа на странице, а запись Supremum (upremum) меньше любого значения первичного ключа на странице. фиктивные записи составляют границы записей на странице соответственно.

Фактические записи строк данных хранятся в пользовательских записях, а конкретная структура записей строк будет подробно описана во втором разделе этой статьи. Свободное пространство хранится в свободном пространстве, а записи удаленных строк будут записаны как свободное пространство. Каталог страниц записывает информацию, связанную с бинарным поиском. File Trailer хранит такие данные, как контрольные суммы, используемые для проверки целостности данных.

источник:woo woo woo.cn blog on.com/not only private/afraid/874…

B+树页结构

Расскажите о других знаниях MySQL на основе дерева B+.

Смотрите здесь, мы узнали о MySQL ототдельные данныеначать проходитьСтраницаЧтобы уменьшить количество дисковых операций ввода-вывода, реализованных на страницекаталог страницчтобы оптимизировать эффективность запросов на странице, затем используйтемногостраничный режимхранить большие объемы данных и в конечном итоге использоватьСтраница содержанияДля достижения эффективности запросов в многостраничном режиме и формирования структуры индекса во рту ——В+ дерево. Теперь, когда мы здесь, давайте поговорим о других аспектах знания MySQL.

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

    О кластеризованных и некластеризованных индексах в[От записи к записи] Базовый дизайн базы данных, из-за которой у людей выпадают волосыВ этой статье уже дано подробное введение. Проще говоря, так называемый кластерный индекс состоит в том, чтобы объединить индекс и данные, и если индекс найден, данные будут найдены. Индекс дерева B +, который мы только что видели, это разновидность кластерного индекса, а не некластеризованного индекса, отделяет данные от индекса, при поиске сначала нужно найти индекс, а потом через индекс можно найти соответствующие данные обратно в таблицу.InnoDB имеет один и только один кластеризованный индекс,а такжеMyISAM — некластеризованный индекс.

  • Принцип соответствия крайнего левого префикса для совместных индексов

    В базе данных MySQL может быть проиндексирован не только столбец, но также может быть установлен совместный индекс для нескольких столбцов, и совместный индекс имеетКонцепция принципа соответствия крайнего левого префикса, будет намного проще понять принцип сопоставления крайнего левого префикса на основе дерева B+.

    Во-первых, мы создаем совместный индекс на основе таблицы в начале текста:

    create index idx_obj on user(age asc,height asc,weight asc)

    Мы уже поняли, что структура данных индекса представляет собой дерево B+, и одним из факторов, оптимизирующих эффективность запросов дерева B+, является сортировка данных, поэтому создание индекса idx_obj эквивалентно созданию Индекс дерева B+, и этот индексСортировка по членам индекса союза, вот возраст, рост, вес. Студенты, которые читали мой предыдущий блог, знают, что пока в InnoDB определен первичный ключ, столбец первичного ключа будет использоваться как кластеризованный индекс, а другие индексы будут использоваться как некластеризованные индексы, поэтому, естественно, этот индекс будет некластеризованным индексом.

    Итак, из них мы можем сделать вывод:

    1. Индекс idx_obj будет отсортирован по возрасту, росту, весу.
    2. Индекс idx_obj является некластеризованным индексом и должен быть возвращен в таблицу при запросе.

    Согласно этим двум выводам, первое, что нужно понять, это как сортировать?

    Сортировка по одному столбцу очень проста, независимо от размера, это может сделать любой, ноКаков принцип сортировки по нескольким столбцам?(акцент)?

    На самом деле в MySQL сортировка объединенного индекса имеет такой принцип,Сравните размеры слева направо, возьмем в качестве примера только что созданный индекс, он сначала сравнит размер возраста, если размер возраста одинаков, то сравнит размер роста, если рост не может сравнить размер, то сравнит размер размер веса, и, наконец, провести этот индекс сортировки.

    Затем в соответствии с этим порядком мы также можем нарисовать дерево B+, которое не такое подробное, как нарисованное выше, упростим его:

    данные:

    多列索引数据

    В+ дерево:

    多列索引结构

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

    Со структурой дерева B+ вы можете понять это через этоПринцип сопоставления крайнего левого префикса.

    Сначала напишем запрос

    SELECT * FROM user WHERE age=1 and height = 2 and weight = 7

    Несомненно, эта инструкция попадет в индекс idx_obj.

    Тогда давайте посмотрим на другое утверждение:

    SELECT * FROM user WHERE height=2 and weight = 7

    подумай немного,Будет ли этот SQL проходить через индекс??

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

    Выше мы упомянули принцип сортировки по нескольким столбцам, который сравнивается и сортируется слева направо, а наш индекс idx_obj — это возраст, рост, вес слева направо, поэтому, когда мы используем рост и вес в качестве условий запроса, из-за отсутствие возраста, нельзя сравнивать с возрастом. Увидев это, у некоторых друзей могут возникнуть вопросы, тогдаРазве не было бы нормально использовать рост и вес для сравнения напрямую?Очевидно, что невозможно, например, мы пишем отсутствующий столбец как hello, тогда условие запроса этого оператора становится ?27, затем мы начинаем с корневого узла дерева B+ в этом уроке, а корневой узел имеет значение 127 и 365, так что если сравнивать рост и вес, то надо переходить на сторону 127, а что если количество пропущенных столбцов больше 3-х? Например, 427, 527, 627, то если вы используете индекс для запроса данных, данные будут потеряны.Запрос ошибки. Так что в данном случае абсолютноНе будет проходить индекс для запроса. ЭтоПроисхождение принципа соответствия крайнего левого префикса.

    1. Самый левый принцип сопоставления префиксов, MySQL всегда будет соответствовать правому, пока не встретит запрос диапазона (>, 5 и d= 6, если создать индекс в порядке (a, b, c, d), d нельзя использовать индекс, если вы создаете индекс (a, b, d, c), вы можете его использовать, и порядок a, b, d можно регулировать произвольно. 2.= и in могут быть не в порядке, например, a = 1 и b = 2 и c = 3. Индекс (a,b,c) может быть построен в любом порядке, и оптимизатор запросов MySQL поможет вам его оптимизировать. в форму, которую индекс может распознать.

    Из того, что мы знаем, можно сделать вывод, что:

    Пока невозможно отсортировать и сравнить размер, совместный индекс не может быть использован..

    Вот еще несколько фраз:

    SELECT * FROM user WHERE age=1 and height = 2

    Этот оператор может принимать индекс idx_obj, потому что он может пройти сравнение (12? 

    SELECT * FROM user WHERE age=1 and weight=7

    Этот оператор также может принимать индекс ind_obj, потому что он также может брать левое поддерево путем сравнения (1?7 

    SELECT * FROM user where age>1

    Этот оператор не будет проходить через индекс, но может проходить через индекс. Что означает это предложение? Этот SQL очень особенный, потому что у него есть индекс, который можно сравнивать, поэтому он также может запрашивать результаты через индекс, но поскольку в этом случае это запрос диапазона и запрос полного поля, если вы используете индекс, вам нужно return to the table, запрос MySQL Оптимизатор подумает, что эффективность индексации ниже, чем эффективность полного сканирования таблицы, поэтому MySQL оптимизирует его и позволит ему выполнить полное сканирование таблицы напрямую.

    SELECT * FROM user WEHRE age=1 and height>2 and weight=7

    Этот оператор может быть проиндексирован, потому что его можно сравнивать по возрасту, но вес не будет использовать индекс, потому что высота - это поиск в диапазоне, аналогично второму оператору, если высота двух страниц больше 2, то MySQL Обе страницы данных будут загружены в память, а затем правильные данные будут сопоставлены по весу.

  • Почему InnoDB имеет только один кластеризованный индекс и не использует кластеризованные индексы для всех индексов?

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

Добавьте два пункта об индексе

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

  1. Что происходит, когда индекс явно создан, но не передается во время выполнения?? Popular Science Time - Query Optimizer Запрос оператора SQL может иметь разные планы выполнения.Что касается того, какой план выбрать в итоге, вам нужно выбрать план с наименьшей стоимостью выполнения через оптимизатор. Перед фактическим выполнением оператора запроса с одной таблицей оптимизатор запросов MySQL выяснит все возможные решения для выполнения оператора, а затем найдет решение с наименьшей стоимостью после сравнения. Этот вариант с наименьшими затратами является так называемым планом выполнения. Процесс оптимизации примерно выглядит следующим образом: 1. Найти все возможные индексы согласно условиям поиска 2. Рассчитать стоимость полного сканирования таблицы 3. Рассчитать стоимость выполнения запросов с использованием разных индексов 4. Сравнить стоимость различных схем выполнения, чтобы найти самая низкая стоимость один . Ссылка на ссылку:nuggets.capable/post/684490…

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

    SELECT * FROM user where age>1

  2. В случае разреженной индексации обычно необходимо возвращать таблицу для запроса данных через указатель конечного узла, а при каких обстоятельствах не нужно возвращаться в таблицу? Время науки - покрывающий индекс Покрывающий индекс (покрывающий индекс) относится к выполнению оператора запроса, который можно получить только из индекса, без необходимости чтения из таблицы данных. Можно также сказать, что достигнут охват индекса. Когда оператор запроса соответствует условиям покрытия индекса, MySQL должен использовать индекс только для возврата данных, требуемых запросом, что позволяет избежать возврата к таблице после нахождения индекса, уменьшая ввод-вывод и повышая эффективность. Например, в таблицеcovering_index_sample есть общий индекс idx_key1_key2(key1,key2). Когда мы передаем оператор SQL: выберите ключ2 из покрывающего_индекса_выборки, где ключ1 = 'keytest';, мы можем выполнить запрос по покрывающему индексу, не возвращаясь к таблице. Ссылка на ссылку:nuggets.capable/post/684490…

    Например:

    SELECT age FROM user where age = 1

    Это предложение не требует запроса таблицы возврата.

Эпилог

Эта статья фокусируется на структуре индекса MySQL, медленно строит индекс дерева B+ с нуля и рассказывает о том, как дерево B+ шаг за шагом оптимизирует эффективность запросов в соответствии с этим процессом.

Подводя итог просто:

Сортировка: Основа оптимизации запросов, сортировка при вставке, на самом деле заключается в оптимизации эффективности запроса.

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

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

Несколько страниц: открывайте новые страницы для сохранения данных при увеличении объема данных.

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

Добро пожаловать в мой личный блог:Object's Blog

Категории