Обмен технологиями

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Оглавление

Индексное приложение

Какие индексы имеет MySQL?

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

Как установить индекс первичного ключа кластеризованного индекса. Вопрос: Что произойдет, если вы его не установите?

Какие поля мы обычно выбираем для построения индексов?

Чем больше индексов, тем лучше?

Как оптимизировать индекс (включая оптимизацию индекса, предотвращение сбоя индекса, увеличение первичного ключа, оптимизацию префиксного индекса)

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

Если я определяю поле даты типа varchar, а одним из данных является «20230922», и если в этом поле даты есть индекс, то если условиемwhere моего запроса является то, где время = 20230922 без одинарных кавычек, будет ли индекс все еще поражен? Почему?

Устранена ли в последней версии MySQL какие-либо случаи сбоя индекса (Индекс функции: значение, рассчитанное функцией, также может быть проиндексировано, механизм сканирования индекса (крайний левый префикс))

Каков крайний левый принцип соответствия?

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

Крайний левый порядок запроса принципа соответствия

Что такое понижение индекса? Добавлено в MySQL5.6 для оптимизации запросов к данным.

Как создать индекс, где a>1, b=2 и c <3?

(A,B,C) совместный индекс выберите * из tbn, где a=? и b в (?,?) и c>?

Как создать совместный индекс, где a>100, b=100 и c=123, упорядоченные по d?

выберите идентификатор, имя из XX, где возраст> 10 и имя типа «xx%», есть совместный индекс (имя, возраст), давайте поговорим о процессе запроса

---

Индексное приложение

MySQLКакие индексы существуют?

Я узнал, что MySQL имеетосновной ключИндекс, уникальный индекс, обычный индекс, префиксный индекс,Индекс СоюзаЭти типы индексов.

Движок Innodb требует, чтобы каждая таблица базы данных имелаосновной ключиндекс，Значения столбца индекса не допускаютсянулевое значение。Например, поле id в таблице является индексом первичного ключа.

Уникальный индекс: Обеспечьте уникальность каждой строки данных в столбце данных, но разрешите значения NULL.

ЗатемДля полей, которые часто запрашиваются, мы можем создать для этого поля обычный индекс.，Если имеется несколько полей, вы можете рассмотреть возможность созданияИндекс Союза,использоватьПокрытие индексаФункции повышают эффективность запросов.

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

В чем разница между обычным индексом и уникальным индексом? Какой из них имеет лучшую производительность обновления? 、

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

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

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

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

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

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

кластерный индексизосновной ключКак установить индекс Вопрос: Что будет, если его не установить?

Когда InnoDB создает кластерный индекс, он выбирает разные столбцы в качестве индексов в соответствии с разными сценариями:

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

2. Если первичного ключа нет, выберитеПервый не содержит НУЛЕВОЕ значениеЕдинственный столбец - это каккластерный индексиндексный ключ

3. При отсутствии любого из вышеперечисленного InnoDB автоматически сгенерирует столбец rowid с неявным автоинкрементом в качестве индексного ключа кластеризованного индекса.

Какие поля мы обычно выбираем для построения индексов?

Сценарии, в которых применимо индексирование:

1. Поля имеют ограничения уникальности, например код продукта

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

3. Поля, часто используемые в GROUPBY и ORDER BY., поэтому при поиске нет необходимости выполнять повторную сортировку, поскольку все записи в дереве B+ сортируются после установления индекса.

Сценарии, не подходящие для индексации

1. Поля, не используемые в условиях WHERE, GROUP BY, ORDER BYзначение индекса — быстрое позиционирование. Если поле не может быть позиционировано, обычно нет необходимости создавать индекс, поскольку индекс будет занимать физическое пространство.

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

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

4. Не рекомендуется использовать неупорядоченные значения.(например, удостоверение личности, UUID) в качестве индекса, когда первичный ключ неизвестен, это приведет к частому разделению конечных узлов и фрагментации дискового хранилища.

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

Чем больше индексов, тем лучше?

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

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

Как оптимизировать индекс? (индекс покрытияОптимизировать и предотвратить сбой индекса,основной ключИнкрементная оптимизация префиксного индекса)

Я использовал эти методы оптимизации

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

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

3. мы хотимИзбегайте записи ошибок индекса SQL Операторы, такие как не выполнять нечеткое сопоставление слева или слева для столбцов индекса, не выполнять вычисления, функции и операции преобразования типов для индексов. Чтобы правильно использовать объединенные индексы, вы должны следовать принципу крайнего левого сопоставления и т. д.В предложении WHERE, если столбец условия перед OR является столбцом индекса, а столбец условия после OR не является столбцом индекса, индекс не будет выполнен.

• Используйте не равно (<>) или NOT: эти операторы обычно делают индекс недействительным, поскольку они сканируют всю таблицу.

• Оператор OR: если в условии запроса используется OR, а условия по обе стороны от OR включают разные индексы, то эти индексы нельзя использовать.

  • использовать OR оператор, еслиOR Условия с обеих сторон включают разные индексы, и в большинстве случаев ядро ​​базы данных не может использовать несколько индексов одновременно для оптимизации запроса.Этопотому что OR Оператору необходимо только выполнить условия с обеих сторон, что увеличивает сложность оптимизации запроса.

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

2. Индекс лучше всего установить на НЕ НУЛЕВОЙ : Чтобы лучше использовать индекс, для столбца индекса должно быть установлено ограничение NOT NULL. Есть две причины:

   1. Наличие NULL в столбцах индекса усложнит выбор индекса оптимизатором, что затруднит оптимизацию таких операций, как подсчет.

   2. Значение NULL — бессмысленное значение, но оно будет занимать физическое пространство. Имеется столбец с нулевым значением.Для хранения NULL будет использоваться как минимум 1 байт пространства. список значений

Если индекс создан, будет ли он использоваться при запросе (сбой индекса,оптимизаторВыберите план выполнения на основе стоимости)

нет.

1. Я узналДаже если запрос использует индекс, он может не использовать индекс.

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

   2. И мы используемИндекс СоюзаЕсли при запросе не соблюдается крайний левый принцип сопоставления, также произойдет сбой индекса.。

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

Если я определяю поле даты типа varchar, а одним из данных является «20230922», и если в этом поле даты есть индекс, то если условиемwhere моего запроса является то, где время = 20230922 без одинарных кавычек, будет ли индекс все еще поражен? Почему?

Не попадет в индекс.

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

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

MySQLУстранена ли в последней версии какие-либо случаи сбоя индекса (индекс функции:расчет функцииЗначение после также может быть проиндексировано и механизм сканирования с пропуском индекса (крайний левый префикс))

Я узнал, что MySQL8.0 может добавлять поляиндекс функции, эта новая функция может решить проблему сбоя индекса при использовании функций в индексе.

Еще одна новая функция —индексный пропуск сканирования, До версии 5.7 при использовании объединенного индекса, если не соблюдается крайний левый принцип сопоставления, произойдет сбой индекса. Однако после того, как в версии 8.0 введена функция пропуска индекса, объединенные индексы все равно можно использовать, даже если самый левый принцип сопоставления. не соблюдается.

Каков крайний левый принцип соответствия?

Предположим, что существует совместный индекс (a, b, c). Его порядок хранения таков: сначала сортировать по a, затем сортировать по b, если a совпадает, а затем сортировать по c, если b совпадает. Благодаря этой особенности при использовании совместных индексов действует принцип крайнего левого сопоставления. Конкретные правила таковы:

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

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

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

УчреждатьИндекс СоюзаЕсть ли что-нибудь, на что нам нужно обратить внимание (наиболее дифференцированные из них расположены в крайнем левом углу, самый левый принцип сопоставления, и индекс не используется после запроса диапазона)

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

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

3. Крайний левый принцип соответствия совместного индекса, вПри обнаружении запроса диапазона (например, >, <) сопоставление прекращается., то есть поля запроса диапазона могут использовать объединенный индекс, но поля, находящиеся за полем запроса диапазона, не могут использовать объединенный индекс.Однако для четырех запросов диапазона >=, <=, BETWEEN и подобных им сопоставлений префиксов сопоставление не прекращается.

   1. В MySQL BETWEEN содержит граничные значения value1 и value2, аналогичные >= и =<.

   2. Ссылка на ссылку https://zhuanlan.zhihu.com/p/573138586

Крайний левый порядок запроса принципа соответствия

select * from T where c=1 and a=2 and b=3;

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

под индексомтолкать Что это такое? Добавлено в MySQL5.6 для оптимизации запросов к данным.

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

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

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

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

select * from t_user where age > 20 and reward = 100000;

Как создать индекс, где a>1, b=2 и c <3?

1. Создайте (abc), (acb), (ab), (ac) индекс сустава, только индекс банки.

2. Создайте (cab), (cba), (ca), (cb) совместные индексы, индексировать может только c.

3. Создайте совместный индекс (ba), индексировать можно как b, так и a.

4. Создайте совместный индекс (bc), индексировать можно как b, так и c.

5. создать (бак) Индекс Союза, b и a можно индексировать, но они медленнее, чем (ба) у совместного индекса есть еще одно преимущество: поле c можетпонижение индекса, уменьшит количество возвратов таблицы;

6. создавать(бса) Индекс Союза, и b, и c могут быть проиндексированы, но у него есть еще одно преимущество, чем совместный индекс (bc), поле a можетпонижение индекса, уменьшит количество возвратов таблицы;

(A,B,C) индекс сустава select * from tbn where a=? and b in (?,?) and c>? Будет ли он индексироваться?

Этот запрос будет использовать совместный индекс (A,B,C), поскольку условие основано на индексном столбце A、B、C Заказ приходит, что является идеальным сценарием использования.

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

2. для B IN (?, ?): Это условие определяет B Столбец может принимать два возможных значения. MySQL будет использовать индекс для поиска всех совпадений.A=? иB Столбец — это запись с любым из этих двух значений.

3. для C>? : Это условие представляет собой запрос диапазона.уже на основеA иB На основе фильтра MySQL продолжит использовать индекс для поискаC Записывает значения столбцов, превышающие указанное значение.

где a>100 и b=100 и c=123 в порядке d, как создатьИндекс Союза?

Я думаюУчреждать bcda чтобыИндекс СоюзаЛучше, в это время поля b и c могут быть проиндексированы, иd может использовать порядок индексов, чтобы избежать сортировки файлов (дополнительная сортировка), хотя последнее поле a не может быть проиндексировано (a не в порядке), его можно сдвинуть вниз с помощью индекса, чтобы уменьшить количество возвратов таблицы.

выберите идентификатор, имя из XX, где возраст > 10 и имя типа 'xx%'，有Индекс Союза(имя, возраст), расскажите о процессе запроса

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

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

Последние запрошенные поля — это id и name. Эти два поля можно найти в объединенном индексе, поэтому нет необходимости возвращать таблицу. Это запрос на покрытие индекса.

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