Comments 14
Интересно, что в оригинале потерялся слеш перед G (похоже, на сайтпонте не умеют форматировать текст для SQL или HTML), а в переводе пропала и сама буква. А вместе с ней и самый первый запрос —
В итоге для многих может быть непонятно, откуда взялся вертикальный формат вывода результатов запроса.
И код в статье, вообще-то, желательно форматировать.
А сама статья неудачная. Объяснений очень мало, примеры я попробовал — не исполняются.
Лучше читать книгу или презентации svetasmirnova
EXPLAIN SELECT * FROM categories\G
В итоге для многих может быть непонятно, откуда взялся вертикальный формат вывода результатов запроса.
И код в статье, вообще-то, желательно форматировать.
А сама статья неудачная. Объяснений очень мало, примеры я попробовал — не исполняются.
Лучше читать книгу или презентации svetasmirnova
Да, строчку забыл, поправил. По поводу G. Там почему-то почти в каждом примере кода в конце непонятная G. Из-за нее код не исполнялся. А примеры исполняются, сам все проверял. Возможно что-то пропущено, но тогда это мое упущение, надо исправить.
Еще раз.
Перед G должен стоять слеш, как в моем примере. Тогда вывод будет такой же, как в статье.
Примеры не исполняются. Таблицы city нет вообще. Можно догадаться что она просто в качестве иллюстрации, но все равно неаккуратно. Для приведенного же дампа запросы исполняются, но заявленный вывод не выдают — все останавливается на Impossible WHERE noticed after reading const tables.
Код в статье надо форматировать
Перед G должен стоять слеш, как в моем примере. Тогда вывод будет такой же, как в статье.
Примеры не исполняются. Таблицы city нет вообще. Можно догадаться что она просто в качестве иллюстрации, но все равно неаккуратно. Для приведенного же дампа запросы исполняются, но заявленный вывод не выдают — все останавливается на Impossible WHERE noticed after reading const tables.
Код в статье надо форматировать
Про форматировать — дельное замечание.
Если вы про помещение его в блок code, то в этом случае получается месиво букв, переносы строк не смог поставить, привести к пристойному виду — тоже. Пришлось в голом виде в тело статьи добавлять. Так хоть переносы строк можно контролировать.
Теперь про это:
Такой таблицы в дампе нет. Это, судя по всему, просто пример произвольного запроса с EXPLAIN и вывод, показанный ниже — это примерный вывод (примерный потому, что нельзя сказать, он точный, т.к. не известна структура исходной таблицы). Там, вроде, так и сказано, что вывод не обязательно может быть таким. Это демонстрация использования ключевого слова EXPLAIN. И второе. Может уровень моих знаний не достаточен. Расскажите, буду знать. Что это за «магическая» в моем понимании G со слешем в конце и каким образом вы получили такой же как в статье вывод на несуществующей таблице? И отдельно по поводу G. Я вот добавляю /G к любому запросу и у меня появляется ошибка.
Таблицы city нет потому, что это тоже просто пример, оторванный от реального мира, чтобы продемонстрировать как использовать ключевое слово EXTENDED и то, как выглядит информация в результате.
Тем более эти запросы приведены до непосредственной ссылки на дамп. А значит логично предположить, что к дампу и другому разделу статьи они никакого отношения не имеют.
Если вы про помещение его в блок code, то в этом случае получается месиво букв, переносы строк не смог поставить, привести к пристойному виду — тоже. Пришлось в голом виде в тело статьи добавлять. Так хоть переносы строк можно контролировать.
Теперь про это:
EXPLAIN SELECT * FROM categories\GТакой таблицы в дампе нет. Это, судя по всему, просто пример произвольного запроса с EXPLAIN и вывод, показанный ниже — это примерный вывод (примерный потому, что нельзя сказать, он точный, т.к. не известна структура исходной таблицы). Там, вроде, так и сказано, что вывод не обязательно может быть таким. Это демонстрация использования ключевого слова EXPLAIN. И второе. Может уровень моих знаний не достаточен. Расскажите, буду знать. Что это за «магическая» в моем понимании G со слешем в конце и каким образом вы получили такой же как в статье вывод на несуществующей таблице? И отдельно по поводу G. Я вот добавляю /G к любому запросу и у меня появляется ошибка.
Таблицы city нет потому, что это тоже просто пример, оторванный от реального мира, чтобы продемонстрировать как использовать ключевое слово EXTENDED и то, как выглядит информация в результате.
Тем более эти запросы приведены до непосредственной ссылки на дамп. А значит логично предположить, что к дампу и другому разделу статьи они никакого отношения не имеют.
Надо добавлять \G, а не /G
Запрос надо помещать не в блок code, а в блок source. С соответствующим языком:
Код, языка для которого не находится — помещать в любой подходящий. Например — HTML
Получается гораздо читабельнее.
Запросы до дампа — это ерунда. Хотя тоже не красит автора.
но проблема в том, что и после дампа вывод эксплейнов не соответствует запросам. И дело совсем не в наличии индексов. Хотя это, опять же — необъяснимая тупость автора. А точнее — лень.
Но дело, повторюсь, не в индексах, а в самом дампе. Запросы не находят данных.
Я, когда готовлю статью, вылизываю исходные данные до последней запятой, перепроверяю по 10 раз. А этот индус тяп-ляп набросал — разбирайтесь сами.
Даже понимая, как должен работать его код, я не буду тратить время на поиск и исправление опечаток. А человек, который, как предполагается, будет изучать explain, вряд ли пройдёт этот квест вообще.
Тщательнее надо подходить к выбору статей для перевода.
А перед написанием статьи на хабр желательно сначала изучить средства форматирования.
Запрос надо помещать не в блок 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, вряд ли пройдёт этот квест вообще.
Тщательнее надо подходить к выбору статей для перевода.
А перед написанием статьи на хабр желательно сначала изучить средства форматирования.
Спасибо за подсказку c source. Так гораздо лучше. А с запросами — раз вы так настойчивы, проверю еще раз. Я вроде написал, что все проверял сам и все работало, но вы этого не заметили, т.к. иначе бы конкретизировали претензию.
Да, это был у меня косяк при импорте. Этот вопрос снимается.
Но наличие индексов в учебном дампе, при том что в примерах требуется сначала база без индексов, а самой статье приведен код для их создания — это всё равно неприемлемо для обучающего материала.
Но наличие индексов в учебном дампе, при том что в примерах требуется сначала база без индексов, а самой статье приведен код для их создания — это всё равно неприемлемо для обучающего материала.
Это да. В статье об этом упомянуто. Когда обнаружил это, то просто решил упомянуть. Ссылка на github. А там я ничего поменять не смогу. Пришлось подстраиваться.
Ну, а про статью. Раз я ее опубликовал, значит думаю, что она достойна опубликования. Да, о том же самом, о чем писали сотню раз. Да, для новичков. Не буду приводить примеры того, что есть здесь и чего я не нашел в других источниках, чтобы не скатываться до обсуждения неправильности/правильности решения о выборе статьи. Для меня оно было правильным, для вас оно может быть другим. По поводу того, что подобное было уже описано. В разных предметных областях пишут кучи книг об одном и том же. Главное — угол зрения. Если данный угол зрения на описанную тему поможет хотя бы одному человеку, то все было не зря.
Могу отметить, что говоря о WHERE, нельзя забывать об ORDER BY.
Запрос такого вида:
Может оказаться быстрее при наличии индекса по table1(field5, field1), а не при наличии индекса по table1(field5, field7, field6).
Запрос такого вида:
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).
А как быть когда есть индексы, но все равно медленно?
Можно пример для понимания? Может какой то индекс лишний или что то еще… Как понять такие вещи?
Например вижу в таблице есть колонка Extras
Вдруг тут что то не так?
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Вдруг тут что то не так?
Sign up to leave a comment.
Использование EXPLAIN. Улучшение запросов