digital-garden/_inbox/Индексы в MySQL.md

34 lines
2.7 KiB
Markdown
Raw Normal View History

2024-06-17 18:42:04 +03:00
---
aliases:
tags:
- зрелость/🌱
date:
- - 2024-06-16
zero-link:
- "[[00 MySQL]]"
parents:
linked:
2024-07-02 19:33:28 +03:00
- "[[Индекс в PostgreSQL]]"
2024-06-17 18:42:04 +03:00
---
![Архитектура](Архитектура%20MySQL.md#^42f122)
Индексы реализуются на уровне движка хранилища, они не стандартизованы. Каждый движок может предоставлять свою реализацию одного и того же индекса. Например, B-Tree индекс в MyISAM хранит указатель на сами данные, а в InnoDB он хранит указатель на первичный ключ; в MyISAM происходит сжатие префиксных индексов, а в InnoDB этого не происходит, но зато там есть кэширование и данных, и индексов.
> [!WARNING] Дублирование индексов
> MySQL никак не управляет дублированием индексов. Например, если создать таблицу с PK, а потом создать на PK индекс и UNIQUE(PK), то мы получим не один, а 3 одинаковых индекса.
Если у нас есть index(A) и index(A,B), то index(A) будет лишним, потому что в случае index(A,B) часть А может использоваться в нем. (если оба [B-tree](B-tree.md))
Используются [покрывающие индексы](Покрывающий%20индекс.md)
[Extended keys MySQL](Extended%20keys%20MySQL.md)
**Когда индексы не работают?**
- Часть выражения: id + 1 = 3.
- Когда есть преобразование типов: key_str = 15
- Несоответсвие кодировок
- Не используется левая часть [составного индекса](Составные%20индексы%20в%20MySQL.md): index(a,b); where b = 5;
- Поиск по суффиксу: '%x'
- Сравнение с исходной таблицей: t.key = t.col
Например, A in (0,1) и А between 0 and 1 это эквивалентные формы, это диапазон и там, и там, но в случае, когда это A in (0,1) список, он понимает, что это не диапазон, а заменяет на множественное условие равенства. В этом случае он будет использовать индекс. Это еще один нюанс MySQL, т.е. нужно смотреть, как писать либо списком, либо ставить <> . Он это различает.