Эта статья призвана рассказать самые скучные базовые знания на самом популярном языке.
Эта тема довольно интересна. Вчера после обеда коллега вдруг что-то сказал:«Есть ли индекс лайка?», я сказал нет, другой коллега возразил и сказал да, а некоторые коллеги сказали да в зависимости от ситуации, это немного сбивает с толку, и я не знаю правильно ли это утверждение, поэтому я решил потратить полчаса на изучение Проверьте этот вопрос и, наконец, получите ответ.
Как это проверить?
Ходят слухи: оптимизация производительности MySQL имеет артефакт, называемый объяснением, который может анализировать оператор выбора и выводить подробную информацию о процессе выполнения выбора, позволяя разработчикам получать идеи оптимизации из этой информации.
Давайте поговорим о команде объяснения, предоставляемой MySQL:
Синтаксис: объясните оператор SQL Например:
1explain select * from user where id=1
После выполнения его вывод имеет следующие поля:
id
select_type
table
partitions
type
possible_keys
key
key_len
ref
rows
Extra
Если вы хотите знать, как использовать объяснение именования, вы должны разобраться в этих полях.
1. id
Идентификатор запроса SELECT, каждому оператору SELECT автоматически присваивается уникальный идентификатор.
2. select_type
Типы, конкретные типы и соответствующие функции каждого предложения запроса select следующие:
имя типа
объяснять
SIMPLE
Простой SELECT, без UNION или подзапросов и т.д.
PRIMARY
Если запрос содержит какие-либо сложные подразделы, самый внешний выбор помечен как PRIMARY.
UNION
Второй или последующий оператор SELECT в UNION
DEPENDENT UNION
Второй или последующий оператор SELECT в UNION, в зависимости от внешнего запроса.
UNION RESULT
Результаты СОЮЗА
SUBQUERY
Первый SELECT в подзапросе
DEPENDENT SUBQUERY
Первый SELECT в подзапросе, в зависимости от внешнего запроса
DERIVED
SELECT производной таблицы, подзапросы предложений FROM
UNCACHEABLE SUBQUERY
Результат подзапроса не может быть кэширован, первая строка внешней ссылки должна быть переоценена
3. table
Он показывает, какую таблицу ищут данные в этой строке, но иногда отображение короткого замыкания не является реальным именем таблицы.
4. partitions
Сопоставление разделов (на данный момент это не очень полезно)
5. type
Тип доступа, указывающий, как MySQL находит нужную строку в таблице, соответствующее значение и интерпретация следующие:
имя типа
Премиум уровень
объяснять
system
1
таблица имеет только одну строку
const
2
Таблица имеет не более одной совпадающей строки, которая считывается в начале запроса.
eq_ref
3
Используйте первичный ключ или уникальный ключ в качестве условия объединения нескольких таблиц, читайте только одну строку из этой таблицы.
ref
4
Индекс, используемый в качестве условия запроса, считывается из таблицы в каждой таблице, которая соответствует значению индекса.
fulltext
5
Полнотекстовый индексный поиск
ref_or_null
6
То же, что и ref, но добавляет поддержку запросов со значением NULL.
index_merge
7
Указывает, что используется метод оптимизации слияния индексов.
unique_subquery
8
Подзапрос in заменяется на
index_subquery
9
Использование заменяет in подзапрос, но только для неуникальных индексов в подзапросе
range
10
Получить только заданный диапазон строк, используя индекс для выбора строк
index
11
Полное сканирование таблицы, но способ сканирования таблицы в порядке индекса
ALL
12
Полное сканирование таблицы для поиска совпадающих строк
В качестве типа доступа значение type представляет собой тип, используемый текущим запросом, что является важным показателем производительности.Как видно из таблицы, сверху вниз способ сканирования таблицы шире и шире, и производительность становится все лучше и лучше Плохо, поэтому для запроса лучше оставаться выше уровня диапазона.
6. possible_keys
Активно указывайте, какой индекс запрос может использовать для поиска записей в таблице. То есть поля, проиндексированные в поле запроса, перечислены, но не обязательно используются запросом.
7. key
Отображает индекс/ключ, фактически используемый в запросе, или NULL, если индекс отсутствует. Но если вы хотите заставить запрос использовать или игнорировать индекс в столбце возможных_ключей, вы можете использовать FORCE INDEX, USE INDEX или IGNORE INDEX в запросе.
8. key_len
Указывает количество байтов, используемых в индексе.
9. ref
Указывает, какие столбцы или константы используются для поиска значений в индексированных столбцах.
10. rows
Отображает предполагаемое количество строк записи текущего запроса, необходимое для поиска совпадающей записи.
11. Extra
Отображает решение, используемое для текущего запроса, который имеет следующие ситуации:
имя типа
объяснять
Using where
Данные столбца возвращаются из таблицы, которая использует только информацию в индексе без фактического действия чтения,
Using temporary
Указывает, что MySQL необходимо использовать временные таблицы для хранения наборов результатов, обычно используемых при сортировке и группировке запросов.
Using filesort
Операция сортировки в MySQL, которую нельзя выполнить с помощью индекса, называется «сортировкой файлов».
Using join buffer
Это изменение подчеркивает, что при получении условия соединения не используется индекс, а для хранения промежуточных результатов требуется буфер соединения. Если это значение присутствует, следует отметить, что в зависимости от специфики запроса может потребоваться добавление индекса для повышения производительности.
Impossible where
Это значение подчеркивает, что инструкция where не приведет ни к каким подходящим строкам.
Select tables optimized away
Это значение означает, что, используя только индекс, оптимизатор может вернуть только одну строку из результата агрегатной функции.
После разговора о грамматике проделаем волну практических операций, сначала создадим таблицу:
1-- 添加索引 2ALTER TABLE test ADD INDEX uname_index (uname);
Проверьте, успешно ли добавлен индекс:
1-- 查看是否有索引 2SHOW INDEX FROM test;
Результат:
Видно, что индекс создан успешно, а дальше добавим немного данных:
1-- 添加一些数据 2INSERT INTO test VALUES(1,'jay'); 3INSERT INTO test VALUES(2,'ja'); 4INSERT INTO test VALUES(3,'bril'); 5INSERT INTO test VALUES(4,'aybar');
Все готово, давайте воспользуемся командой объяснения, чтобы выяснить, есть ли индексы у подобных операторов. Есть четыре случая подобного, а именно нет%, %%, левый%, правый%,
1. как имя поля
1EXPLAIN SELECT * FROM test WHERE uname LIKE 'j';
Результат:
Как можно видеть: Значение типа: диапазон, а значение ключа — uname_index, что означает, что в данном случае используется индекс.
2. как %имя поля%
1EXPLAIN SELECT * FROM test WHERE uname LIKE '%j%';
Результат:
Как можно видеть: Значение типа равно ALL, что означает полное сканирование таблицы, а значение ключа равно NULL, что означает, что индекс не используется.
3. нравится % имя поля
1EXPLAIN SELECT * FROM test WHERE uname LIKE '%j';
Результат:
Как можно видеть: Значение типа равно ALL, значение ключа равно NULL, индекс также не используется.
4. нравится имя поля%
1EXPLAIN SELECT * FROM test WHERE uname LIKE 'j%';
Результат:
Как можно видеть: Значение типа: диапазон, а значение ключа — uname_index, что означает, что в данном случае используется индекс.
Суммировать
Из приведенного выше эксперимента мы можем обобщить правило использования индекса like: Чтобы подобный оператор сделал индекс эффективным, он не может начинаться с % после того, как, то есть (например, % имя поля%), (например, % имя поля), такие операторы сделают индекс недействительным, и (например, имя поля), (например, имя поля) %) Этот тип индекса оператора можно использовать как обычно.
разное
Чтобы проверить проблему подобного индекса, я изучил волшебное объяснение MySQL, но объяснение может не только проверить использование индекса, но и предоставить много других советов по оптимизации производительности.Что касается конкретного использования, то оно такое же, как и Результаты перечислены, а затем вы можете получить соответствующий контент, выполнив поиск в соответствующих полях.
Думаете, эта статья была вам полезна? пожалуйста, поделитесь с большим количеством людей Обратите внимание на «Безграничное программирование» и улучшите свои навыки принуждения.