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

Пожалуйста, укажите источник! ! ! Самородки:Птицы не гадят

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

1. Индекс

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

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

Прежде всего, индекс MySQL в основном основан на хеш-таблице или дереве B+.

Во-вторых, структура данных индекса

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

Бинарные деревья

Бинарное дерево — это древовидная структура, в которой каждый узел имеет не более двух ветвей (то есть нет узлов со степенью ветвления больше 2). Часто упоминается как «левое поддерево» и «правое поддерево».

левое поддерево

i-й уровень бинарного дерева имеет не более 2^(i-1) узлов,

Двоичное дерево с глубиной K имеет в общей сложности не более 2 ^ k-1 узлов (определяя глубину k0 = 0, где расположен корневой узел), а общее количество совпадающих узлов называется «полным двоичным деревом». ";

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

Заодно изучите структуру данных, здесь тоже рекомендуетсяData Structure VisualizationsПри обучении вы можете очень интуитивно видеть процесс, разрешенный структурой данных, и четко видеть, как идти шаг за шагом.

найти один изBinary Search Treesбинарное дерево

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

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

Рекомендуемое чтение:Википедия — Бинарное дерево

Красно-черные деревья

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

Красно-черное дерево имеет сложную структуру, но его работа имеет хороший наихудший случай.часы работы, и эффективен на практике: он может выполнять поиск, вставку и удаление за время O(log n), где n — количество элементов в дереве.

Красно-черные деревья подчиняются следующим принципам:

1. Узлы красные или черные.
2. Корни черные.
3. Все листья черные (листья — узлы NIL).
4. У каждого красного узла должно быть два черных потомка. (Не может быть двух последовательных красных узлов на всех путях от каждого листа к корню.)
5. от любого узла к каждому его листупростой путьоба содержат одинаковое количество черных узлов.

Ниже приведен пример конкретного красно-черного дерева:

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

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

Также вData Structure VisualizationsвыберитеRed-Black TreesОперация вставки красно-черного дерева может интуитивно видеть процесс вставки красно-черного дерева.

Точно так же красно-черные деревья не подходят для индексов MySQL, после того, как объем данных будет большим, несколько слоев также станут больше.

Рекомендуемое чтение:

Википедия - Красно-черные деревья

Программист Little Grey - красное черное дерево

Другие структурные проблемы

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

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

• Линейная структура: чтение/запись в среднем O(n) раз
• бинарное дерево поиска (BST): в среднем O(log2(n)) операций чтения/записи; наихудшее чтение/запись O(n) раз, если дерево несбалансировано
• Самобалансирующееся бинарное дерево поиска (AVL): добавлен алгоритм самобалансировки на основе BST, а максимальное время чтения/записи составляет O(log2(n)) раз.
• красно-черное дерево (RBT): другое самобалансирующееся дерево поиска, чтение/запись не более O(log2(n)) раз

BST,AVL,RBTОчень хорошо оптимизировать количество операций чтения и записи с O(n) до O(log2(n)); где,AVLиRBTчемBSTС добавлением функций самобалансировки количество операций чтения и записи сокращается до максимального значения O(log2(n)).

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

B-деревья

Также известен как: многостороннее сбалансированное дерево поиска. Большинство механизмов хранения поддерживают индексы B-tree. B-дерево обычно означает, что все значения хранятся по порядку и что каждый листовой узел находится на одинаковом расстоянии от корня. Индексы B-дерева могут ускорить доступ к данным, поскольку подсистеме хранения больше не нужно выполнять полное сканирование таблицы для получения данных. На рисунке ниже показано простое B-дерево.

В B-дереве внутренние (неконечные) узлы могут иметь различное количество дочерних элементов (с предопределенным диапазоном номеров). Когда данные вставляются или удаляются из узла, количество его дочерних элементов изменяется. Внутренние узлы могут быть объединены или разделены, чтобы оставаться в пределах заданного числа.

Как показано ниже:

• Листовые узлы имеют одинаковую глубину, указатель конечного узла равен нулю.
• Все проиндексированные элементы не повторяются
• Индексы данных в узлах расположены в порядке возрастания слева направо
• И промежуточные узлы, и конечные узлы несут данные спутниковых данных (записи данных, на которые указывают элементы индекса).

Демонстрируется только процесс вставки, в котором операции удаления и поиска могут выполняться через удаление и поиск. Интуитивно почувствуйте процесс выполнения B-дерева.

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

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

Каталог таблицы страниц - это расширенная внешняя память + ускоренное чтение и запись диска.Страница (Page) обычно 4К (равна размеру блока блока данных диска, см. разбор инода и блока).Загрузить в память( чтобы амортизировать стоимость поиска), изменить страницу и записать страницу обратно на диск по необязательному расписанию. Учитывая хороший характер таблицы страниц, размер каждого узла можно сделать примерно равным одной странице (что делает m очень большим), так что каждая загруженная страница может полностью покрыть узел, чтобы можно было выбрать следующий уровень поддерева; Дерево такое же. Для таблицы страниц AVL (или RBT) эквивалентен B-дереву с поддеревьями 1 ключ + 2. Поскольку логически соседние узлы обычно не являются смежными физически, читается страница размером 4 КБ, и на странице нет абсолютно никаких узлов. Большая часть пространства будет недействительными данными.

Предполагая, что указатели узлов ключа и поддерева занимают 4 байта, узел B-дерева является самым большим.m * (4 + 4) = 8m B; Размер страницы 4 КБ. ноm = 4 * 1024 / 8m = 512, B-дерево с 512 ответвлениями, данные 1000 Вт, максимальная глубинаlog(512/2)(10^7) = 3.02 ~= 4. Глубина контрастного бинарного дерева, такого как AVL, равнаlog(2)(10^7) = 23.25 ~= 24, разница более чем в 5 раз. Шок! Глубина индекса B-дерева такова!

Тогда почему число B настолько велико, и появление дерева B+ должно решить проблему дерева B

1, это количество линий позиционирования

2. Не может обрабатывать запросы диапазона

Вопрос 1: Количество рядов для позиционирования

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

1. Непосредственно сохраните строку данных (может соответствовать нескольким строкам), соответствующую ключу в дочернем узле.
2. Строка данных хранится отдельно, к узлу добавляется поле для определения положения ключа, соответствующего строке данных.
3. Измените логику суждения ключа и поддерева, чтобы поддерево было больше или равно предыдущему ключу и меньше следующего ключа, и, наконец, все доступы попадут на конечный узел; конечный узел непосредственно хранит строку данных или положение строки данных.

Схема 1 напрямую проходит, хранение строк данных уменьшит количество поддеревьев на странице, а m уменьшится, а высота дерева увеличится.

Поле добавляется к узлу схемы 2, предполагая, что это указатель 4B, новыйm = 4 * 1024 / 12m = 341.33 ~= 341, максимальная глубинаlog(341/2)(10^7) = 3.14 ~= 4.

Узел m и глубина схемы 3 не изменяются, но временная сложность становится стабильной O(logm(n)).

Вариант 3 можно рассмотреть.

Проблема 2: Не удается обработать запросы диапазона

В реальном бизнесе частота запросов диапазона очень высока, и B-дерево может найти только одну позицию индекса (может соответствовать нескольким строкам), что затрудняет обработку запросов диапазона. Меньшие изменения - это 2 варианта:

1. Без изменений, при запросе сначала находится левая граница, затем правая граница, а затем DFS (или BFS) проходит узлы между левой границей и правой границей.
2. На основе «Задачи 1-Схема 3», поскольку все строки данных хранятся в конечных узлах, листовые узлы B-дерева также упорядочены, и можно добавить указатель, указывающий на следующий листовой узел текущего листовой узел в порядке первичного ключа. ; При запросе сначала найдите левую границу, затем правую границу, а затем линейно пройдите от левой границы к ограниченной.

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

Википедия-B-дерево

Программист Little Ash-B-tree

B+деревья (B+деревья)

Основные изменения описаны выше:

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

Оглядываясь назад на предыдущее B-дерево,B-дерево порядка m имеет следующие характеристики:

1. Корневой узел имеет не менее двух дочерних узлов.

2. Каждый промежуточный узел содержит k-1 элементов и k потомков, где m/2

3. Каждый листовой узел содержит k-1 элементов, где m/2

4. Все листовые узлы расположены на одном уровне.

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

Дерево B+ порядка m имеет следующие характеристики:

1. Промежуточный узел с k поддеревьями содержит k элементов (k-1 элементов в дереве B), каждый элемент не хранит данные, он используется только для индексации, а все данные хранятся в листовых узлах.

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

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

Сводка характеристик дерева B+

Дерево B+ — это обновленная версия дерева B., который имеет следующие характеристики

• Нелистовые узлы не хранят данные, только индексы (избыточные), и можно разместить больше индексов.
• Конечные узлы содержат все поля индекса
• Конечные узлы связаны с указателями для повышения производительности доступа к диапазону.
• Только конечные узлы имеют данные спутниковых данных (записи данных, на которые указывают элементы индекса).

Также вData Structure VisualizationsвыберитеB+ TreesОперация вставки дерева B+ позволяет интуитивно видеть процесс вставки.

Как видно из анимации, каждый листовой узел B+-дерева имеет указатель на следующий узел, который объединяет все конечные узлы. Данные индекса хранятся в листовых узлах.

В чем преимущества дерева B+ по сравнению с деревом B:

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

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

3. Все конечные узлы образуют упорядоченный связанный список, что удобно для запроса диапазона.

Подводя итог, дерево B+ имеет три преимущества перед деревом B: 1. Меньше времени ввода-вывода, 2. Стабильная производительность запросов, 3. Простой запрос диапазона.

Рекомендуемое чтение:

Дерево Википедии-B+

Программист Xiaohui-B+ дерево

Хэш-индекс

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

1. Хэш-индекс может удовлетворять только запросам '=', 'IN', '', то есть запросу равного значения, и не может использовать запрос диапазона. очень ограничено
   1. Поскольку хеш-индекс сравнивает хеш-значение после операции хеширования, его можно использовать только для фильтрации по эквивалентности, а не для фильтрации по диапазону, поскольку отношение размера хеш-значения, обработанного соответствующим хеш-алгоритмом, использовать нельзя. быть точно таким же, как до операции хеширования.
2. Поскольку хэш-индекс реализуется через хэш-таблицу, он не сортируется сам по себе.
   1. Поскольку хэш-индекс сохраняет значение хэша после вычисления хэша, а отношение размера хеш-значения не обязательно точно такое же, как значение ключа до операции хеширования, база данных не может использовать данные индекса, чтобы избежать какой-либо операции сортировки;
3. Хэш-индексы нельзя запрашивать с помощью ключей частичного индекса.
   1. Для комбинированного индекса при вычислении хеш-значения Hash-индекса ключи комбинированного индекса объединяются, а затем хэш-значение вычисляется вместе, вместо того, чтобы вычислять хеш-значение по отдельности, поэтому при запросе через первый один или несколько ключей индекса комбинированного индекса нельзя использовать также хэш-индекс.
4. Хэш-индексы не могут избежать сканирования таблиц в любое время.
   1. Как мы уже знаем, хэш-индекс предназначен для хранения хэш-значения результата операции хеширования и соответствующей информации об указателе строки в хеш-таблице после того, как ключ индекса подвергается операции хеширования.Количество записей данных с хэш-ключом значение не может быть напрямую запрошено из хеш-индекса, все равно необходимо сравнить фактические данные в таблице и получить соответствующий результат.
5. Производительность хэш-индекса не обязательно выше, чем у индекса B-Tree, когда большое количество значений хэша равно.
   1. Для индексных ключей с низкой избирательностью, если создается хэш-индекс, будет большое количество информации указателя записи, связанной с одним и тем же значением хэша. Таким образом, будет очень проблематично найти определенную запись, что приведет к трате нескольких обращений к табличным данным, что приведет к низкой общей производительности.

3. Механизм базы данных MySQL

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

MyISAM

Создайте новую таблицу t_test_myisam, движок использует MyISAM, проверьте исходный файл, и вы увидите, что там 3 файла.

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

Первичный индекс (первичный индекс)

Механизм MyISAM использует B+Tree в качестве структуры индекса, а данные конечного узла хранят адрес записи данных. На следующем рисунке показана схема индекса первичного ключа MyISAM.

Среди них Col1 является первичным ключом.Видно, что индексный файл MyISAM сохраняет только адрес записи данных.

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

Создайте вспомогательный индекс на Col2, как показано на схематической диаграмме вспомогательного индекса, как показано ниже.

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

Алгоритм поиска индекса в MyISAM заключается в том, чтобы сначала найти индекс в соответствии с алгоритмом поиска B + Tree.Если указанный ключ существует, вынуть значение его поля данных, а затем использовать значение поля данных в качестве адреса для прочитать соответствующую запись данных.

InnoDB

Создайте новую таблицу t_test_innodb, движок использует InnoDB, проверьте исходный файл, и вы увидите, что там 2 файла.

Первичный индекс (первичный индекс)

Индексы и данные InnoDB находятся в одном файле.

Структура индекса организована в соответствии с B+Tree.

Конечные узлы содержат полные записи данных и индексы. Этот индекс называетсякластеризованный индекс.

Ключ индекса является первичным ключом данных, поэтому сам файл данных таблицы InnoDB является первичным индексом.

Как показано ниже:

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

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

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

Вспомогательный указатель, в качестве указателя используйте название второй строки пути, как показано на рисунке.

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

Из-за характеристик реализации индексов InnoDB рекомендуется использовать целочисленный первичный ключ с автоинкрементом.

Есть три преимущества:

1. Самоувеличивающийся ключ обычно представляет собой целочисленный тип, такой как int, и ключ относительно компактен, так что m может быть очень большим, а индекс занимает мало места. Самый крайний пример, если использовать varchar 50B (включая длину), тоm = 4 * 1024 / 54m = 75.85 ~= 76, максимальная глубинаlog(76/2)(10^7) = 4.43 ~= 5, плюс стоимость промаха кэша и сравнения строк, затраты времени значительно возрастают. В то же время, когда ключ увеличивается с 4B до 50B, занимаемое пространство всего дерева индексов также является чрезвычайно ужасающим (если вторичный индекс использует первичный ключ для поиска строк данных, рост пространства будет еще более серьезным).
2. Все базовые сравнения данных индексов MySQL являются целочисленными сравнениями.Если первичный ключ имеет строковый тип и в нем есть английский язык, для сравнения необходимо преобразовать код ASCII. Поэтому не рекомендуется использовать uuid в качестве первичного ключа.
3. Самоувеличивающийся первичный ключ заставляет вставку строк данных располагаться крайне справа от номера индекса, а частота разбиения узлов низкая.B+TreeРеальная работа процесса вставки. Если это немонотонный первичный ключ, в процессе вставки будет происходить значительная перегруппировка узлов, что не способствует первоначальному замыслу оптимизации индекса.

Разница между индексами InnoDB и индексами MyISAM

Во-первых, разница между первичными индексами: файлы данных InnoDB сами по себе являются файлами индексов. А индекс и данные MyISAM разделены.

Во-вторых, разница между вспомогательными индексами: поле данных вспомогательного индекса InnoDB хранит значение первичного ключа соответствующей записи вместо адреса. И вторичный индекс MyISAM не сильно отличается от первичного индекса.

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

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

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

Пять, совместный индекс

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

На приведенном выше рисунке есть три совместных индекса, сверху вниз, строго отсортированные.

6. Предложения по оптимизации

Соответствие крайнего левого префикса

Индекс может быть простым, состоящим из одного столбца (a), или сложным, состоящим из нескольких столбцов (a, b, c, d), т.е.联合索引. Если это совместный индекс, ключ также состоит из нескольких столбцов. В то же время индекс может использоваться только для определения того, существует ли ключ (равный), и не может быть сопоставлен в дальнейшем при обнаружении запросов диапазона (>,

Если есть индекс (a, b, c, d), условие запросаa = 1 and b = 2 and c > 3 and d = 4, он последовательно попадет в a, b и c в каждом узле и не попадет в d. То есть самый левый принцип сопоставления префиксов.

=, в порядке автоматической оптимизации

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

Если есть индекс (a, b, c, d), условие запросаc > 3 and b = 2 and a = 1 and d < 4иa = 1 and c > 3 and b = 2 and d < 4Порядок в порядке, MySQL автоматически оптимизируетa = 1 and b = 2 and c > 3 and d < 4, последовательно нажмите a, b, c.

Столбцы индекса не могут участвовать в вычислениях

Условия запроса с индексированными столбцами, участвующими в расчете, не дружественны к индексу (даже индекс нельзя использовать), напримерfrom_unixtime(create_time) = '2014-05-29'.

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

Поэтому индексированные столбцы не могут участвовать в вычислении. вышесказанноеfrom_unixtime(create_time) = '2014-05-29'заявление должно быть написано какcreate_time = unix_timestamp('2014-05-29').

Не создавайте новые индексы, если их можно расширить

Если у вас уже есть индекс (a) и вы хотите создать индекс (a, b), попробуйте изменить индекс (a) как индекс (a, b).

Стоимость создания нового индекса легко понять. Если индекс (a) изменен на индекс (a, b), MySQL может напрямую изменить индекс (a, b) в дереве B+ индекса a посредством разделения, слияния и т. д.

Нет необходимости создавать индекс с префиксом отношения включения.

Если у вас уже есть индекс (a, b), вам не нужно создавать индекс (a), но при необходимости вам все равно нужно подумать о создании индекса (b).

Преимущества и недостатки индексации

преимущество

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

недостаток

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