Использование EXPLAIN. Улучшение запросов

[FanatPHP]

Интересно, что в оригинале потерялся слеш перед G (похоже, на сайтпонте не умеют форматировать текст для SQL или HTML), а в переводе пропала и сама буква. А вместе с ней и самый первый запрос —

EXPLAIN SELECT * FROM categories\G

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

А сама статья неудачная. Объяснений очень мало, примеры я попробовал — не исполняются.
Лучше читать книгу или презентации svetasmirnova

[hbuser]

Да, строчку забыл, поправил. По поводу G. Там почему-то почти в каждом примере кода в конце непонятная G. Из-за нее код не исполнялся. А примеры исполняются, сам все проверял. Возможно что-то пропущено, но тогда это мое упущение, надо исправить.

[FanatPHP]

Еще раз.
Перед G должен стоять слеш, как в моем примере. Тогда вывод будет такой же, как в статье.
Примеры не исполняются. Таблицы city нет вообще. Можно догадаться что она просто в качестве иллюстрации, но все равно неаккуратно. Для приведенного же дампа запросы исполняются, но заявленный вывод не выдают — все останавливается на Impossible WHERE noticed after reading const tables.
Код в статье надо форматировать

[hbuser]

Про форматировать — дельное замечание.
Если вы про помещение его в блок code, то в этом случае получается месиво букв, переносы строк не смог поставить, привести к пристойному виду — тоже. Пришлось в голом виде в тело статьи добавлять. Так хоть переносы строк можно контролировать.

Теперь про это:

EXPLAIN SELECT * FROM categories\G

Такой таблицы в дампе нет. Это, судя по всему, просто пример произвольного запроса с EXPLAIN и вывод, показанный ниже — это примерный вывод (примерный потому, что нельзя сказать, он точный, т.к. не известна структура исходной таблицы). Там, вроде, так и сказано, что вывод не обязательно может быть таким. Это демонстрация использования ключевого слова EXPLAIN. И второе. Может уровень моих знаний не достаточен. Расскажите, буду знать. Что это за «магическая» в моем понимании G со слешем в конце и каким образом вы получили такой же как в статье вывод на несуществующей таблице? И отдельно по поводу G. Я вот добавляю /G к любому запросу и у меня появляется ошибка.

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

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

[FanatPHP]

Надо добавлять \G, а не /G
Запрос надо помещать не в блок code, а в блок source. С соответствующим языком:

EXPLAIN SELECT * FROM
orderdetails d
INNER JOIN orders o ON d.orderNumber = o.orderNumber
INNER JOIN products p ON p.productCode = d.productCode
INNER JOIN productlines l ON p.productLine = l.productLine
INNER JOIN customers c on c.customerNumber = o.customerNumber
WHERE o.orderNumber = 10101

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

EXPLAIN SELECT * FROM categories

********************** 1. row **********************
id: 1
select_type: SIMPLE
table: categories
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4
Extra:
1 row in set (0.00 sec)

Получается гораздо читабельнее.

Запросы до дампа — это ерунда. Хотя тоже не красит автора.
но проблема в том, что и после дампа вывод эксплейнов не соответствует запросам. И дело совсем не в наличии индексов. Хотя это, опять же — необъяснимая тупость автора. А точнее — лень.
Но дело, повторюсь, не в индексах, а в самом дампе. Запросы не находят данных.
Я, когда готовлю статью, вылизываю исходные данные до последней запятой, перепроверяю по 10 раз. А этот индус тяп-ляп набросал — разбирайтесь сами.
Даже понимая, как должен работать его код, я не буду тратить время на поиск и исправление опечаток. А человек, который, как предполагается, будет изучать explain, вряд ли пройдёт этот квест вообще.

Тщательнее надо подходить к выбору статей для перевода.
А перед написанием статьи на хабр желательно сначала изучить средства форматирования.

[hbuser]

Спасибо за подсказку c source. Так гораздо лучше. А с запросами — раз вы так настойчивы, проверю еще раз. Я вроде написал, что все проверял сам и все работало, но вы этого не заметили, т.к. иначе бы конкретизировали претензию.

[FanatPHP]

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

[hbuser]

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

[FanatPHP]

Ну, вообще-то, github — это синоним слова «поменять». Весь смысл гитхаба — это возможность одной кнопкой сделать форк и менять в нём всё, что только заблагорассудится. Потом можно дать ссылку на свой репозиторий с исправленной версией.

[hbuser]

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

[hbuser]

Ну, а про статью. Раз я ее опубликовал, значит думаю, что она достойна опубликования. Да, о том же самом, о чем писали сотню раз. Да, для новичков. Не буду приводить примеры того, что есть здесь и чего я не нашел в других источниках, чтобы не скатываться до обсуждения неправильности/правильности решения о выборе статьи. Для меня оно было правильным, для вас оно может быть другим. По поводу того, что подобное было уже описано. В разных предметных областях пишут кучи книг об одном и том же. Главное — угол зрения. Если данный угол зрения на описанную тему поможет хотя бы одному человеку, то все было не зря.

[akzhan]

Могу отметить, что говоря о WHERE, нельзя забывать об ORDER BY.

Запрос такого вида:

SELECT table1.field1, table1.field2, table1.field3 FROM table1 INNER JOIN table2 ON (table1.field4 = table2.field1)
WHERE table1.field5 IN (?, ?, ?) AND table1.field6 NOT LIKE 'Europe/%' ANВ table1.field7 = ?
ORDER BY table1.field1
 LIMIT ?, ?

Может оказаться быстрее при наличии индекса по table1(field5, field1), а не при наличии индекса по table1(field5, field7, field6).

[qant]

А как быть когда есть индексы, но все равно медленно?

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
         LEFT JOIN wp_postmeta
                   ON (wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'layf_exclude_from_feed')
         LEFT JOIN wp_postmeta AS mt1 ON (wp_posts.ID = mt1.post_id)
         LEFT JOIN wp_icl_translations wpml_translations ON wp_posts.ID = wpml_translations.element_id AND
                                                               wpml_translations.element_type =
                                                               CONCAT('post_', wp_posts.post_type)
WHERE 1 = 1
  AND (wp_posts.post_date > '2019-09-02 23:59:59')
  AND (wp_postmeta.post_id IS NULL OR (mt1.meta_key = 'layf_exclude_from_feed' AND mt1.meta_value != '1'))
  AND wp_posts.post_type IN ('property', 'post')
  AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'expired')
  AND (((wpml_translations.language_code = 'ru' OR 0) AND
        wp_posts.post_type IN ('post', 'page', 'attachment', 'wp_block', 'property', 'service')) OR
       wp_posts.post_type NOT IN ('post', 'page', 'attachment', 'wp_block', 'property', 'service'))
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
LIMIT 0, 300;

Можно пример для понимания? Может какой то индекс лишний или что то еще… Как понять такие вещи?

Например вижу в таблице есть колонка Extras
Using where; Using index; Using temporary; Using filesort

Вдруг тут что то не так?

[FanatPHP]

тут что то не так?

Using temporary; Using filesort

для начала выкинуть в ужасе SELECT SQL_CALC_FOUND_ROWS, поскольку это смерть запроса и тормоза.
после этого упрощать запрос пока проблема сохраняется
и потом отлаживать его. проставляе те индексы, которые нужны, а не вообще "индексы"