Анализ оптимизации индекса MySQL

MySQL

Анализ оптимизации индекса MySQL

Почему ваш sql-запрос работает медленно? Почему индексы, которые вы создаете, часто терпят неудачу? Из содержания этой главы вы узнаете причины снижения производительности MySQL, введение в индексы, принципы создания индексов, использование команды объяснения и значение поля вывода объяснения. Помочь вам понять индексы, анализировать индексы, использовать индексы и писать операторы SQL с более высокой производительностью. Чего же ты ждешь? Засучите рукава и сделайте это!

анализ случая

Давайте кратко разберемсянереляционная база данныхиРеляционная база данныхразница.
MongoDB — это тип NoSQL. Полное название NoSQL не только SQL, нереляционная база данных. Он характеризуетсявысокая производительность,Сильное расширение,Гибкий режим, что особенно заметно в сценариях с высокой степенью параллелизма. Но в настоящее время это лишь дополнение к реляционной базе данных, и между ней и реляционной базой данных все еще существует определенный разрыв с точки зрения согласованности данных, безопасности данных и сложности запросов.
MySQL — это тип реляционной базы данных.Сильная функция запроса,Высокая согласованность данных,Высокая безопасность данных,Поддержка вторичного индекса. Однако производительность немного уступает MongoDB, особенно данные уровня более одного миллиона, что подвержено явлению медленного запроса. На данный момент необходимо проанализировать причины медленного выполнения запроса, как правило, SQL программиста написана плохо, или нет индекса ключа, или индекс недействителен.
База данных ERP-системы компании в основном состоит из MongoDB (NoSQL, наиболее близкой к реляционным данным), за которой следует Redis, и MySQL составляет лишь небольшую часть. Теперь снова используем MySQL благодаря системе Qimen от Alibaba и системе Jushita. Учитывая, что количество заказов превышает миллион, анализ производительности MySQL особенно важен.

Начнем с двух простых примеров. Функция и значение каждого параметра будут подробно описаны позже.
Описание: SQL, который нужно использовать, выложен на github.Если вам это нравится, вы можете нажать звездочку, ха-ха.GitHub.com/IT дракон Б…

Сценарий 1: импорт заказа, избегайте повторного импорта заказа через номер транзакции

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

Самый простой оператор sql

mysql> select * from itdragon_order_list where transaction_id = "81X97310V32236260E";
+-------+--------------------+-------+------+----------+--------------+----------+------------------+-------------+-------------+------------+---------------------+
| id    | transaction_id     | gross | net  | stock_id | order_status | descript | finance_descript | create_type | order_level | input_user | input_date          |
+-------+--------------------+-------+------+----------+--------------+----------+------------------+-------------+-------------+------------+---------------------+
| 10000 | 81X97310V32236260E |   6.6 | 6.13 |        1 |           10 | ok       | ok               | auto        |           1 | itdragon   | 2017-08-18 17:01:49 |
+-------+--------------------+-------+------+----------+--------------+----------+------------------+-------------+-------------+------------+---------------------+

mysql> explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table               | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |    33.33 | Using where |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+-------------+скопировать код

Нет проблем ни с самим запросом, ни с автономной тестовой средой. Однако, как только функция будет запущена, возникнет проблема медленного запроса. Сотни и десятки миллионов заказов, использовать полное сканирование таблицы? А? Хм!
Откуда вы знаете, что sql выполняет полное сканирование таблицы? С помощью команды объяснения становится ясно, как MySQL обрабатывает операторы SQL. Печатное содержимое представляет собой:
id: Серийный номер запроса — 1.
select_type: тип запроса — простой запрос, а простой оператор выбора не имеет объединений и подзапросов.
table: Это таблица itdragon_order_list.
partitions: Нет раздела.
type: тип соединения, все означает полное сканирование таблицы.
possible_keys: Может использовать индекс как null.
key: Фактический используемый индекс равен нулю.
key_len: Длина индекса, конечно, тоже нулевая.
ref: с ключом не используется столбец или параметр.
Extra: где используется запрос.
Поскольку в базе данных всего три фрагмента данных, строки и отфильтрованная информация малопригодны. Здесь важно понимать, что тип — ALL, а производительность полного сканирования таблицы — худшая, если предположить, что в базе миллионы данных, то без помощи индексов она аварийно застрянет.

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

mysql> create unique index idx_order_transaID on itdragon_order_list (transaction_id);
mysql> explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------+
| id | select_type | table               | partitions | type  | possible_keys      | key                | key_len | ref   | rows | filtered | Extra |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | const | idx_order_transaID | idx_order_transaID | 453     | const |    1 |      100 | NULL  |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------+скопировать код

Созданный здесь индекс является уникальным, а не обычным индексом.
Значение типа, напечатанное уникальным индексом, равно const. Указывает, что индекс можно найти один раз. То есть, когда значение найдено, сканирование завершается и возвращается результат запроса.
Значение типа, напечатанное нормальным индексом, равно ref. Указывает на сканирование неуникального индекса. Если значение найдено, продолжайте сканирование, пока индексный файл не будет просканирован. (код здесь не опубликован)
Очевидно, что производительность const намного выше, чем у ref. И, судя по бизнес-логике, разумно создать уникальный индекс.

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

mysql> explain select transaction_id from itdragon_order_list where transaction_id = "81X97310V32236260E";
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------------+
| id | select_type | table               | partitions | type  | possible_keys      | key                | key_len | ref   | rows | filtered | Extra       |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | const | idx_order_transaID | idx_order_transaID | 453     | const |    1 |      100 | Using index |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------------+скопировать код

здесь будетselect * fromизменился наselect transaction_id fromЗадний
Дополнительно отображается Использование индекса, указывающее, что запрос использует покрывающий индекс, что является очень хорошей новостью, так как производительность инструкции sql хорошая. Если в подсказке используется сортировка файлов (используется внутренняя сортировка) и используется временное использование (используется временная таблица), это означает, что sql необходимо оптимизировать немедленно.
В соответствии с бизнес-логикой структура запроса возвращает transaction_id для удовлетворения требований бизнес-логики.

Сценарий 2, страница управления заказами, отсортированная по уровню заказа и времени ввода заказа

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

Самый простой оператор sql

mysql> explain select * from itdragon_order_list order by order_level,input_date;
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table               | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |      100 | Using filesort |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+скопировать код

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

Предварительная оптимизация: создаем составной индекс для order_level, input_date

mysql> create index idx_order_levelDate on itdragon_order_list (order_level,input_date);
mysql> explain select * from itdragon_order_list order by order_level,input_date;
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table               | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |      100 | Using filesort |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+скопировать код

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

mysql> explain select order_level,input_date from itdragon_order_list order by order_level,input_date;
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------------+
| id | select_type | table               | partitions | type  | possible_keys | key                 | key_len | ref  | rows | filtered | Extra       |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | index | NULL          | idx_order_levelDate | 68      | NULL |    3 |      100 | Using index |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------------+скопировать код

будетselect * fromзаменяетсяselect order_level,input_date fromЗадний. Тип изменяется с all на index, указывая (полное сканирование индекса) полное сканирование файла индекса, а Extra также показывает, что используется покрывающий индекс. Но это неправильно! ! ! ! Хотя поиск выполняется быстро, возвращаемый контент имеет только два поля: order_level и input_date.Как его могут использовать коллеги по бизнесу? Можно ли построить составной индекс для каждого поля?
MySQL не так глуп, вы можете использовать принудительный индекс Принудительное указание индекса. Изменить исходный оператор sqlforce index(idx_order_levelDate)Вот и все.

mysql> explain select * from itdragon_order_list force index(idx_order_levelDate) order by order_level,input_date;
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------+
| id | select_type | table               | partitions | type  | possible_keys | key                 | key_len | ref  | rows | filtered | Extra |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | index | NULL          | idx_order_levelDate | 68      | NULL |    3 |      100 | NULL  |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------+скопировать код

Повторная оптимизация: действительно ли нужно сортировать уровень заказа?

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

mysql> explain select * from itdragon_order_list where order_level=3 order by input_date;
+----+-------------+---------------------+------------+------+---------------------+---------------------+---------+-------+------+----------+-----------------------+
| id | select_type | table               | partitions | type | possible_keys       | key                 | key_len | ref   | rows | filtered | Extra                 |
+----+-------------+---------------------+------------+------+---------------------+---------------------+---------+-------+------+----------+-----------------------+
|  1 | SIMPLE      | itdragon_order_list | NULL       | ref  | idx_order_levelDate | idx_order_levelDate | 5       | const |    1 |      100 | Using index condition |
+----+-------------+---------------------+------------+------+---------------------+---------------------+---------+-------+------+----------+-----------------------+скопировать код

По сравнению с предыдущим sql тип изменен с index на ref (сканирование неуникального индекса). Длина индекса изменилась с 68 до 5, что указывает на то, что используется только один индекс. ref также является константой. Дополнительно используется условие индекса, что означает автоматический выбор сканирования индекса или полного сканирования таблицы в соответствии с критическим значением. В целом производительность намного лучше, чем у предыдущего sql.

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

Введение в индексирование

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

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

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

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

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

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

Основной синтаксис: Создать:

create [unique] index indexName on tableName (columnName...)
alter tableName add [unique] index [indexName] on (columnName...)скопировать код

Удалить:

drop index [indexName] on tableNameскопировать код

Проверять:

show index from tableNameскопировать код

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

При каких обстоятельствах нельзя строить индекс:
1 В таблице слишком мало записей, и нет необходимости создавать индекс для данных ниже миллиона уровней
2 Таблицы, которые часто добавляются, удаляются и изменяются, не нуждаются в создании индексов
3 Поля с повторяющимися данными и равномерным распределением не нуждаются в создании индексов, таких как true, false и им подобных.
4 Часто обновляемые поля не подходят для создания индексов
5 Поля, которые не используются там, где условия не нужно индексировать

анализ производительности

Собственное узкое место MySQL

Проблемы с производительностью, которые сама MySQL видит, заключаются в недостатке места на диске, слишком большом количестве дисковых операций ввода-вывода и низкой производительности аппаратного обеспечения сервера.
1 ЦП: насыщение ЦП обычно происходит, когда данные загружаются в память или считываются с диска.
2 IO: узкое место дискового ввода-вывода возникает, когда загруженные данные намного превышают объем памяти.
3 узких места производительности серверного оборудования: top, free, iostat и vmstat для просмотра состояния производительности системы

объясните, анализирует оператор sql

Используйте ключевое слово объяснения, чтобы имитировать оптимизатор, выполняющий оператор SQL-запроса, чтобы узнать, как MySQL обрабатывает оператор SQL.

+----+-------------+-------+------------+------+---------------+-----+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-----+---------+------+------+----------+-------+скопировать код

id

Порядковый номер запроса на выборку, который содержит набор повторяющихся чисел, указывающих порядок, в котором операторы SQL выполняются в запросе. Обычно бывает три ситуации:
Первый тип: все id одинаковые, а порядок выполнения sql сверху вниз;
Второй тип: идентификаторы все разные, и порядок выполнения sql выполняется первым в соответствии с большим идентификатором;
Третий тип: id существует как одинаковый, так и разный. Сначала выполнить в соответствии с большим идентификатором, а затем выполнить сверху вниз в соответствии с тем же идентификатором.

select_type

Тип запроса на выборку, который в основном используется для различения общих запросов, совместных запросов и вложенных сложных запросов.
simple: простой запрос на выборку, не содержащий подзапросов или объединений.
primary: если запрос содержит какие-либо сложные подзапросы, самый внешний запрос помечается как основной.
subquery: содержит подзапросы в списках select или where
derived: подзапросы, содержащиеся в списке from, помечаются как производные. MySQL будет рекурсивно выполнять эти подзапросы, помещая результаты во временную таблицу.
union: если второй выбор появляется после объединения, он будет помечен как объединение.Если объединение включено в подзапрос предложения from, внешний выбор будет помечен как: производный
union result: выберите, чтобы получить результаты из таблицы объединения

partitions

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

type

Это очень важный параметр, тип соединения, общие из них: all, index, range, ref, eq_ref, const, system, null восемь уровней.
Производительность от лучшей к худшей: system > const > eq_ref > ref > range > index > all
Для java-программистов, если вы гарантируете, что запрос достигает хотя бы уровня диапазона или, предпочтительно, ref, это отличный и ответственный программист.
all:(полный сканирование таблицы) полное сканирование таблицы, несомненно, является худшим, если объем данных исчисляется миллионами, полное сканирование таблицы будет очень медленным.
index: (полное сканирование индекса) Полное сканирование файла индекса намного лучше всех, ведь поиск данных из индексного дерева выполняется быстрее, чем поиск данных из полной таблицы.
range: Получить только заданный диапазон строк, используя индекс для сопоставления строк. Диапазон сужается и, конечно, быстрее, чем полное сканирование таблицы и полное сканирование файлов индекса. Операторы SQL обычно имеют между, в, >, ref: сканирование неуникального индекса, которое по сути является доступом к индексу, возвращает все строки, соответствующие одному значению. Например, при запросе всех коллег, принадлежащих к группе исследований и разработок в компании, совпадающие результаты представляют собой несколько, но не уникальных значений.
eq_ref: Уникальное сканирование индекса, для каждого ключа индекса есть одна соответствующая ему запись в таблице. Например, если вы запрашиваете генерального директора компании, результатом сопоставления может быть только одна запись.
const: указывает, что его можно найти по индексу один раз, а const используется для сравнения первичного ключа или уникального индекса. Поскольку сопоставляется только одна строка данных, MySQL может быстро преобразовать запрос в константу, если первичный ключ помещен в список where.
system: В таблице есть только одна запись (равная системной таблице), представляющая собой специальный столбец типа const, который обычно не отображается, просто поймите

possible_keys

Отображает индекс (один или несколько или null), который может использоваться оператором запроса, но не обязательно используется запросом. Только для информационного использования.

key

Отображает индекс, фактически используемый оператором запроса. Если ноль, индекс не используется.

key_len

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

ref

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

rows

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

extra

Using filesort: Указывает, что MySQL будет использовать внешний индекс для сортировки данных вместо чтения в порядке индексов в таблице. Операция сортировки в MySQL, которую нельзя выполнить с помощью индекса, называется «сортировкой файлов». В этом случае следует немедленно оптимизировать sql.
Using temporary: Временные таблицы используются для сохранения промежуточных результатов, а MySQL использует временные таблицы при сортировке результатов запроса. Обычно используется в порядке сортировки и группировки по запросу. В этом случае следует немедленно оптимизировать sql.
Using index: Указывает, что соответствующая операция выбора использует покрывающий индекс (Covering index), чтобы избежать доступа к строкам данных таблицы, и эффект хороший! Если одновременно появляется сообщение Using where, это означает, что индекс используется для поиска значения ключа индекса. Если в то же время нет Using where, это означает, что индекс используется для чтения данных, а не для выполнения действия поиска.
Индекс покрытия: также называется покрытием индекса, то есть столбец данных выбора может быть получен только из индекса, без чтения строки данных, MySQL может использовать индекс для возврата полей в списке выбора без повторного чтения в соответствии с индексный файл данных.
Using index condition: новая функция, добавленная после версии 5.6, оптимизатор будет выбирать, использовать ли индекс или выполнять полный обход таблицы в соответствии с отношением количества записей в диапазоне RANGE к общему количеству, когда индекс существует.
Using where: Указывает, что при использовании фильтрации
Using join buffer: указывает, что используется кэш подключения.
impossible where: Значение оператора where всегда ложно, недоступно и не может быть использовано для получения каких-либо элементов.
distinct: оптимизация отдельной операции и прекращение поиска одного и того же значения после нахождения первого совпадающего кортежа.

filtered

Процентное значение, используемое в сочетании со значением столбца rows для оценки набора результатов предыдущей таблицы в плане выполнения запроса (QEP) для определения количества циклов для операции соединения. Маленькие таблицы управляют большими таблицами, сокращая количество подключений.

Благодаря введению параметра объяснения мы можем узнать:
1 Порядок чтения таблицы (id)
2 Тип операции операции чтения данных (тип)
3 Какие индексы используются на самом деле (ключ)
4 Ссылки между таблицами (ссылка)
5 Сколько строк в таблице запрашивается оптимизатором (строк)

Причины снижения производительности

С точки зрения программиста
1 Оператор запроса написан не очень хорошо
2 Индекс не построен, индекс построен необоснованно или индекс недействителен
3 В реляционном запросе слишком много соединений
С точки зрения сервера
1 Недостаточно места на сервере
2 Необоснованные настройки параметров конфигурации настройки сервера

Суммировать

1 Индекс — это структура данных, которая отсортирована и обеспечивает быстрый поиск. Его цель — повысить эффективность запроса.
2 После создания индекса запросы к данным становятся быстрее, но обновление данных становится медленнее.
3 Причиной снижения производительности, вероятно, является сбой индекса.
4 Принцип создания индекса, поля, которые часто запрашиваются, подходят для создания индексов, а данные, которые необходимо часто обновлять, не подходят для создания индексов.
5 Поля индекса часто обновляются, или физическое удаление данных таблицы может легко привести к сбою индекса.
6 Используйте объяснение для анализа операторов sql
7 Помимо оптимизации оператора sql, вы также можете оптимизировать дизайн таблицы. Например, попробуйте сделать запрос к одной таблице, чтобы уменьшить связь между таблицами. Оформление картотечных столов и т.д.

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

использованная литература

Порядок MySQL по оптимизации сортировки:blog.51CTO.com/US TB80/1073…

автор:ITDragon Дракон

Источник:www.cnblogs.com/itdragon/

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

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