Ответ
Оператор EXPLAIN (или EXPLAIN ANALYZE в PostgreSQL) возвращает план выполнения запроса. Ключевые поля в выводе MySQL/ MariaDB:
id: Уникальный идентификатор каждого шага в плане выполнения.select_type: Тип операцииSELECT(например,SIMPLE,PRIMARY,SUBQUERY,DERIVED).table: Имя таблицы, к которой относится строка вывода.partitions: Какие разделы (partitions) были затронуты.type: Критически важное поле — тип соединения или доступа к таблице. ОтALL(полное сканирование) доconst/system(по уникальному ключу).ALL: Наихудший вариант, сканирование всех строк.index: Сканирование всего индекса.range: Сканирование диапазона индекса.ref/eq_ref: Поиск по не-уникальному/уникальному индексу.const: Поиск по первичному или уникальному ключу, возвращает не более одной строки.
possible_keys: Какие индексы теоретически могут быть использованы для этой таблицы.key: Фактически выбранный оптимизатором индекс.key_len: Длина используемой части ключа индекса (в байтах).ref: Какие столбцы или константы сравниваются с индексом (key).rows: Оценочное количество строк, которое должно быть проверено.filtered: Примерный процент строк, которые будут отфильтрованы условиемWHERE.Extra: Дополнительная информация о том, как выполняется запрос (например,Using where,Using index,Using temporary,Using filesort).
Пример для MySQL:
EXPLAIN SELECT * FROM orders WHERE customer_id = 100 AND status = 'shipped';Результат может показать, используется ли индекс по customer_id, сколько строк примерно будет просмотрено (rows) и не пришлось ли делать временную таблицу или файловую сортировку (Extra).
Ответ 18+ 🔞
А, EXPLAIN, ёпта! Ну это как заглянуть под капот своей тачки, когда она жрёт бензина дохуя и едет как черепаха. Сейчас разжуем, что там за поля вылазят, чтобы понять, где у твоего запроса тормоза.
Смотри, когда ты пишешь EXPLAIN SELECT ..., база тебе вываливает целый план, как она собирается эту хуйню выполнять. Главное — не охуеть от количества цифр, а смотреть на ключевые моменты.
Вот на что смотреть в первую очередь, чтобы не облажаться:
type— это, блядь, самое главное поле. Оно показывает, КАК база лезет в таблицу. Если тутALL— это пиздец, полный провал. Значит, она будет читать ВСЕ строки подряд, как дура. Это как искать иголку в стоге сена, перебирая каждую травинку. Нормальные значения — этоrefилиeq_ref(нашёл по индексу),range(сканирует диапазон по индексу).const— вообще идеал, значит нашёл по уникальному ключу мгновенно.key— а вот это, сука, индекс, который она реально выбрала для работы. Если тутNULL, а вpossible_keysсписок есть — значит оптимизатор, тот пидарас шерстяной, решил, что проще всё просканировать. Волнение ебать!rows— оценочное количество строк, которые ей придётся перелопатить. Если цифра овердохуища, типа сотни тысяч, а ты ждёшь одну запись — это тревожный звоночек. Подозрение ебать чувствую.Extra— тут всякая дополнительная фигня, которая может добить. ВидишьUsing filesortилиUsing temporary— готовься, блядь. Это значит, что для выполнения твоего запроса ей пришлось создать временную таблицу или отсортировать результат в файле, а это ой как медленно. Если видишьUsing index— расслабься, чувак, это хорошо, запрос выполнился прямо из индекса, даже в таблицу лезть не пришлось.
Вот смотри на примере, чтобы было понятнее:
EXPLAIN SELECT * FROM orders WHERE customer_id = 100 AND status = 'shipped';Допустим, в ответе будет:
type: ref— ну, уже неплохо, использует индекс.key: idx_customer— работает по индексу наcustomer_id. Ладно.rows: 5— проверит всего 5 строк, окей.Extra: Using where— значит, после того как нашла по индексу, ещё будет фильтровать поstatus = 'shipped'прямо на месте.
А могло быть и хуёвей: type: ALL, key: NULL, rows: 1000000, Extra: Using where. Вот это уже пизда рулю, запрос будет выполняться до второго пришествия. Надо срочно индекс какой-нибудь на customer_id или на пару полей добавлять.
Короче, EXPLAIN — это твой лучший друг, когда что-то тормозит. Не ленись, сука, заглядывай туда, прежде чем орать, что база — говно. Чаще всего проблема в кривом запросе, а не в железе. Сам от себя охуеешь, когда найдёшь причину.
