«Это первый день моего участия в первом испытании обновлений 2022 года. Подробную информацию о мероприятии см.:Вызов первого обновления 2022 г.".

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

💎Введение в колонку

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

Мы всегда обманываем себя и думаем, что можем оптимизировать через другие аспекты, но не хотим с этим сталкиваться.Расширенный MySQL, переключитесь на изучение того, что кажется более «продвинутым», изучитеRedis, чтобы разделить давление MySQL, изучить промежуточное ПО, такое как MyCat, и реализоватьрепликация master-slave,разделение чтения-записи,Подбиблиотека и подтаблицаи т.п. (Правильно о мело)
​

Когда пришло время готовиться к интервью, я обнаружил, что MySQL в вопросе интервью задает три вопроса~

А ультрасовременный промежуточный софт я изучил сам, просил совсем немного! ! Только сам умею им пользоваться.При написании резюме могу только слабо написать "понять" ххх промежуточное ПО...
​

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

​

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

👉Краткий обзор этой статьи

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

• Что такое индекс
• Реализация базового индекса
• Что такое кластерный индекс? Как насчет вторичных индексов?
• крайний левый префикс
• Как разработать индекс, принципы, которым нужно следовать
• Синтаксис, связанный с индексом

​

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

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

• Но боюсь, что когда я обновлюсь, вам будет неудобно меня найти ххх (высокий EQ требует внимания🤣)

определение индекса

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

По сути, индекс — это отсортированная структура данных.

​

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

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

• ускоритьнайтиа такжеСортироватьскорость, снизить затраты на ввод-вывод базы данных и потребление ЦП
• Создавая уникальный индекс, можно гарантировать уникальность каждой строки данных в таблице базы данных.

Недостаток индекса

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

Но на самом деле мы не используем MySQL вбинарное дерево поискахранить, зачем?

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

структура индекса

Индексирование реализовано на уровне механизма хранения MySQL, а не на уровне сервера. Поэтому индексы каждого механизма хранения не обязательно одинаковы, и не все механизмы поддерживают все типы индексов.
​

• BTREE-индекс: самый распространенный тип индекса, большинство индексов поддерживают индексы B-tree.
• HASH-индекс: Поддерживается только механизмом памяти, сценарий использования прост.
• Индексы R-дерева (пространственные индексы): Пространственный индекс — это специальный тип индекса движка MyISAM. Он в основном используется для типов геопространственных данных. Обычно он используется меньше и не будет вводиться отдельно.
• Полнотекстовый (полнотекстовый индекс): Полнотекстовый индекс также является специальным типом индекса MyISAM, который в основном используется для полнотекстового индекса InnoDB поддерживает полнотекстовый индекс, начиная с Mysql 5.6.

MyISAM, InnoDB, память три механизма хранения поддерживают различные типы индексов

показатель	двигатель ИННОДБ	двигатель MYISAM	ПАМЯТЬ двигателя
Индекс BTREE	служба поддержки	служба поддержки	служба поддержки
HASH-индекс	не поддерживается	не поддерживается	служба поддержки
Индекс R-дерева	не поддерживается	служба поддержки	не поддерживается
Full-text	Поддерживается после версии 5.6	служба поддержки	не поддерживается

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

BTREE

Многостороннее сбалансированное дерево поиска, m-порядок (m-вилка) BTREE удовлетворяет:

• Каждый узел имеет не более m дочерних элементов
  • Количество детей: от ceil(m/2) до m
  • Количество ключевых слов: от ceil(m/2)-1 до m-1

ceil означает округление вверх, ceil(2.3)=3

Вставить регистр ключевого слова

Гарантированно не разрушает свойства B-деревьев m-порядка.

Из-за 3-го порядка узлов может быть не более 2, поэтому 26 и 30 в начале вместе, а потом еще 85 начнет расщепляться, 30 - среднее верхнее положение, 26 сохраняется, а 85 уходит в правильно
который:верхнее среднее положение, затем оставайтесь в старом узле слева и переходите к новому узлу справа

Когда 70 снова вставляется, как показано на рисунке, 70 — это просто верхняя позиция в средней позиции, тогда 62 сохраняется, а 85 делится на новый узел.

Нужно разделить после подъема

Продолжайте разделяться вверх, то же самое верно

сравнительное преимущество

По сравнению с бинарным деревом поиска высота/глубина ниже, а эффективность естественного запроса выше.

B+TREE

• B+-деревья имеют два типа узлов: внутренние узлы (также называемыеинода)илистовой узел. Внутренние узлы не являются листовыми узлами.Внутренние узлы не хранят данные, только индексы, а данные хранятся в листовых узлах.
• Ключи во внутренних узлахОт малого к большомуДля ключа во внутреннем узле все ключи в левом дереве меньше его, а все ключи в правом поддереве больше или равны ему. Записи в листовых узлах также упорядочены по размеру ключа.
• Каждый листовой узел имеет указатель на соседний листовой узел, а сам листовой узел зависит от размера ключевого слова.От малого к большомупоследовательные ссылки.
• родительский узел существуетиндекс первого элемента правого потомка.

​

сравнительное преимущество

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

​

B+дерево в MySQL

Структура данных индекса MySql оптимизирована для классического B+Tree. На основе исходного B+Tree добавьтеУказатель связанного списка на соседний конечный узел (общая структура аналогична двусвязному списку), формируется B+Tree с последовательными указателями, что повышает производительность интервального доступа.
​

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

• отПереход от бинарного дерева поиска к B-дереву, есть существенное изменение, заключающееся в том, что узел может хранить несколько данных, что эквивалентно хранению нескольких данных в одном блоке диска, что значительно сокращает время ввода-вывода! !

Схематическая диаграмма структуры индекса B+Tree в MySQL:
Простое бинарное дерево поиска:

Принцип индекса

Индекс BTree:

Введение в инициализацию

Светло-синий цвет называется блоком диска, вы можете видеть, что каждый блок диска содержит несколько элементов данных (показаны темно-синим цветом) и указатели (показаны желтым цветом).
Например, блок диска 1 содержит элементы данных 17 и 35, включая указатели P1, P2, P3,
P1 представляет дисковые блоки меньше 17, P2 представляет дисковые блоки от 17 до 35, а P3 представляет дисковые блоки больше 35.

• Реальные данные существуют в листовых узлахто есть 3, 5, 9, 10, 13, 15, 28, 29, 36, 60, 75, 79, 90, 99. `
• Нелистовые узлы не хранят реальные данные, а только хранятЭлементы данных, определяющие направление поиска, такие как 17, 35 фактически не существуют в техпаспорте. `

Найти процесс

Если вы хотите найти элемент данных 29, то сначала с диска в память будет загружен дисковый блок 1, а в это время произойдет IO. Используйте двоичный поиск в памяти, чтобы определить, что 29 находится между 17 и 35, и заблокируйте указатель P2 блока диска 1. Время памяти очень короткое (по сравнению с дисковым вводом-выводом) и может быть проигнорировано. указатель дискового блока 1 Дисковый блок 3 загружается с диска в память, происходит второй IO, 29 находится между 26 и 30, указатель P2 дискового блока 3 заблокирован, дисковый блок 8 загружается в память через указатель, третий Происходит ввод-вывод, и в то же время память проходит через двоичный поиск до 29, завершая запрос, всего три операции ввода-вывода.

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

🎈 Классификация индексов

В InnoDB таблицы хранятся в виде индексов в соответствии с порядком первичных ключей.Таблицы в этом методе хранения называются индексно-организованными таблицами. И поскольку мы упоминали ранее, InnoDB использует модель индекса дерева B+, поэтому данные хранятся в дереве B+.
​

Каждый индекс соответствует дереву B+ в InnoDB.
Предположим, у нас есть таблица с первичным ключом в качестве идентификатора, поле k в таблице и индекс по k.
Оператор создания таблицы для этой таблицы:

mysql> create table T( 
  id int primary key, 
  k int not null,  
  name varchar(16), 
  index (k))engine=InnoDB; 

Значения (ID,k) R1~R5 в таблице равны (100,1), (200,2), (300,3), (500,5) и (600,6) соответственно, пример Схема двух деревьев выглядит следующим образом:

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

индекс первичного ключа

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

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

Вторичный индексСодержимое листового узлазначение первичного ключа. В InnoDB вторичные индексы также называютсявторичный индекс(вторичный индекс).
​

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

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

​

​

В соответствии с приведенной выше структурой индекса давайте обсудим проблему:В чем разница между запросами на основе индекса первичного ключа и вторичного индекса?
​

• Если оператор select * from T, где ID=500, то есть метод запроса первичного ключа, вам нужно только выполнить поиск в дереве идентификаторов B+;
• Если оператор select * from T, где k=5, то есть обычный метод индексного запроса, вам нужно сначала выполнить поискk индексное дерево, значение идентификатора равно 500,Затем к дереву индексов IDИскать один раз. Этот процесс называетсяформа возврата.

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

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

При этом вторичный индекс делится на следующие виды (просто сначала пропустите его, а о нем мы узнаем позже):
​

• Уникальный ключ: Уникальный индекс также является ограничением.Столбец атрибутов уникального индекса не может содержать повторяющиеся данные, но данные могут иметь значение NULL, и для таблицы можно создать несколько уникальных индексов.Целью создания уникального индекса является в основном уникальность данных столбца атрибутов, а не эффективность запроса.
• Обыкновенный индекс (индекс):Единственной функцией обычных индексов является быстрый запрос данных.Таблица позволяет создавать несколько обычных индексов, допускает дублирование данных и NULL.
• Префикс: Индексация префикса доступна только для данных строкового типа. Индекс префикса предназначен для создания индекса первых нескольких символов текста, а данные, созданные обычным индексом, меньше, поскольку берутся только первые несколько символов.
• Полнотекстовый индекс (полный текст): Полнотекстовое индексирование в основном используется для извлечения информации о ключевых словах в больших текстовых данных и является технологией, используемой в настоящее время в базах данных поисковых систем. До Mysql5.6 только движок MYISAM поддерживал полнотекстовое индексирование, после 5.6 InnoDB также поддерживал полнотекстовое индексирование.

🧵Расширение -- раскрывающийся список индексов

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

Мы установили композитный индекс (имя, состояние, адрес), и индекс также хранится в соответствии с этим полем, аналогично следующему рисунку:

Дерево составного индекса (для возвращаемых таблиц сохраняются только столбцы индекса и первичные ключи)

name	status	address	идентификатор (первичный ключ)
Сяоми 1	0	1	1
Сяоми 2	1	1	2

Мы выполняем такой оператор:

SELECT name FROM tb_seller WHERE name like '小米%' and status ='1' ;

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

3. найти второй -Сяоми 2, судя по статусу=1, затем идем по id=2дерево индексов первичного ключаНайдите его и получите все данные

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

крайний левый префикс

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

1. По лестнице от низкого к высокому прыжка нет - на этот раз в соответствии с принципом крайнего левого префикса индекс не будет недействительным.

2. прыжки

• Напрямую название первого слоя не идет, конечнонедействителен

• Я поднялся на первый этаж, но потом сразу пошел на третий этаж, толькоТот, что перед прыжком, не провалится (здесь удается только имя)

• В то же время этот порядок не определяется порядком нашего where, например:
  • где имя = «Технология Xiaomi», статус = «1» и адрес = «Пекин».
  • где status='1' и name='Xiaomi Technology' и address='Пекин'

Хотя порядок полей в where разный, второй вроде бы более продвинутый, но по факту эффект тот же

На самом деле, поскольку у нашего MySQL естьOptimizer(оптимизатор запросов), оптимизатор запросов оптимизирует SQL и выберет оптимальный план запроса для выполнения.

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

🎐 Принципы построения индекса

для стола

1. Частота запросов высокая,Много данныхТаблица

для полей

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

🎡Другие принципы

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

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

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

Например:

Мы создали три индекса с одним столбцом: имя, статус, адрес

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

оптимальный индекс: В частности, это означает, что в таблице запросов наиболее узнаваемые (наименьшая доля) индексный столбец, например здесьaddressЕсть очень узнаваемыйДанные «Сиань Сити»;

​

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

4. Используя крайний левый префикс, например, есть N полей, нам не обязательно создавать N индексов, мы можем использоватьсоставной индекс

То есть мы пытаемся создавать составные индексы вместо одноколоночных.

创建复合索引:
	CREATE INDEX idx_name_email_status ON tb_seller(name,email,status);

就相当于
	对name 创建索引 ;
	对name , email 创建了索引 ;
	对name , email, status 创建了索引 ;

⏰ Дайте каштан

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

CREATE TABLE `tuser` (
  `id` int(11) NOT NULL,
  `name` varchar(32) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
) ENGINE=InnoDB

Если вы хотите построить здесьсоставной индекс, каким принципам мы должны следовать?
​

Изменяя порядок, можно сохранить на один индекс меньше

• Например, в наших бизнес-требованиях есть два метода запроса:
  1. Запрос по имени
  2. Запрос по имени и возрасту

Если мы создадим индекс (возраст, имя), то по принципу крайнего левого префикса мы можем сделать с этим индексом запрос по возрасту, возрасту и имени, а не просто по имени (потому чтопрыгнул), чтобы удовлетворить наши потребности, мы должны создать еще один индекс имен;
​

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

Учитывайте пробел -> короткий индекс

• Например, в наших бизнес-требованиях есть следующие два метода запроса:
  1. Запрос по имени
  2. Запрос по возрасту
  3. Запрос по имени и возрасту

У нас есть два варианта:

1. Создайте совместный индекс (имя, возраст) и создайте индекс с одним столбцом: возрастной индекс.
2. Установить совместный указатель (возраст, имя), установить одноколонный указатель: именной указатель.

​

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

Когда строить индекс

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

Когда будет индекс

1. В таблице очень мало данных
2. часто меняющаяся таблица
3. Часто обновляемые поля
4. Данные дублируются и равномерно распределяются(например, содержит много повторяющихся данных, то бинарный поиск дерева мультифорков не очень полезен, его можно понимать как O(logn) деградацию)

Синтаксис, связанный с индексом

создать индекс

По умолчанию будет создан индекс для первичного ключа --primary

CREATE 	[UNIQUE|FULLTEXT|SPATIAL]  INDEX index_name 
[USING  index_type]
ON tbl_name(index_col_name,...)

index_col_name : column_name[(length)][ASC | DESC]

поисковый индекс

Добавьте \G в конце, чтобы превратить его в вертикальное отображение экрана.

select index from tbl_name\G;

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

drop INDEX index_name on tbl_name ;

изменить индекс

1). alter  table  tb_name  add  primary  key(column_list); 
	该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL	
	
2). alter  table  tb_name  add  unique index_name(column_list);
	这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）
	
3). alter  table  tb_name  add  index index_name(column_list);
	添加普通索引， 索引值可以出现多次。
	
4). alter  table  tb_name  add  fulltext  index_name(column_list);
	该语句指定了索引为FULLTEXT， 用于全文索引

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

show status like 'Handler_read%';	 -- 查看当前会话索引使用情况

show global status like 'Handler_read%';	-- 查看全局索引使用情况

Handler_read_first: количество раз, когда была прочитана первая запись в индексе. Если высокое, сервер выполняет много полных сканирований индекса (чем меньше значение, тем лучше).
​

Handler_read_key: если индекс работает, это значение представляет собой количество раз, когда строка была прочитана значением индекса, если значение ниже, улучшение производительности индекса невелико, поскольку индекс используется нечасто (чем выше значение, тем лучше).
​

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

Handler_read_prev: количество запросов на чтение предыдущей строки в ключевом порядке. Этот метод чтения в основном используется для оптимизации ORDER BY... DESC.
​

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

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

🎆Сводка

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

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

2. Классификация индекса:

   1. индекс первичного ключа
   2. Вторичный индекс

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

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

4. Синтаксис, связанный с индексом, прост в использовании.

5. Просмотр использования индекса.

💠Следующее превью

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

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

🖨 Ссылки

• Самородки:nuggets.capable/post/684490…
• Думаю нет:сегмент fault.com/ah/119000002…
• MySQL45 разговор
• Темная лошадка MySQL расширенный

Фавориты = белая проституция, лайк + подписка настоящая любовь! ! ! Если в этой статье что-то не так, укажите это в области комментариев и добро пожаловать в мой WeChat для общения:Melo__Jun

🧿Сеть друзей

• 🎉Моя годичная репетиционная карьера за кулисами

• Поговорим о Java

• Практика распределенной разработки

• Начало работы с Redis

• Структуры данных и алгоритмы

Заключительные мысли: у этой коллекции в два раза больше лайков 😷