Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

EXPLAIN — Самая мощная команда MySQL

MySQL *
Перевод
Самая мощная команда в MySQL – это EXPLAIN. EXPLAIN может в точности рассказать вам, что происходит, когда вы выполняете запрос. Эта информация позволит вам обнаружить медленные запросы и сократить время, затрачиваемое на обработку запроса, что впоследствии может значительно ускорить работу вашего приложения.
Читать дальше →
Всего голосов 26: ↑22 и ↓4 +18
Просмотры 141K
Комментарии 33

Что интересного нам расскажет EXPLAIN EXTENDED?

MySQL *
Перевод
Большинство разработчиков на MySQL знакомы с командой EXPLAIN, однако значительно меньше людей знают о команде EXPLAIN EXTENDED, появившуюся ещё в MySQL 4.1, и ещё меньше умеют ею пользоваться.

EXPLAIN EXTENDED умеет показывать, что же конкретно делает с Вашим запросом оптимизатор MySQL. Для разработчика может быть совсем не очевидно, насколько сильно может отличаться написанный им запрос от того, который в действительности будет выполнен сервером. Этот процесс называется механизмом перезаписи запросов (query-rewrite), и он является частью любого хорошего SQL-оптимизатора. Команда EXPLAIN EXTENDED добавляет дополнительные предупреждения (warnings) к выводу команды EXPLAIN, в том числе и переписанный SQL-запрос.
Читать дальше →
Всего голосов 63: ↑60 и ↓3 +57
Просмотры 11K
Комментарии 29

Как расширение индекса в InnoDB таблицах удивительным образом снижает производительность

MySQL *
Перевод
Один из видов оптимизации, который мы часто используем, это расширение индекса. Он подходит, если есть запросы, использующие другие части составного ключа. И обычно это безопасно, но есть некоторые случаи, где производительность катастрофически падает.

Рассмотрим пример.
Читать дальше →
Всего голосов 71: ↑68 и ↓3 +65
Просмотры 3.9K
Комментарии 61

Объясняя необъяснимое

Разработка веб-сайтов *PostgreSQL *SQL *
Перевод
Друзья, мы с радостью продолжаем публикацию интересных материалов, посвященных самым разнообразным аспектам работы с PostgreSQL. Сегодняшний перевод открывает целую серию статей за авторством Hubert Lubaczewski, которые наверняка заинтересуют широкий круг читателей.



Одна из первых вещей, которую слышит новоиспеченный администратор баз данных – «используй EXPLAIN». И при первой же попытке он сталкивается c непостижимым:

                                                        QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=146.63..148.65 rows=808 width=138) (actual time=55.009..55.012 rows=71 loops=1)
   Sort Key: n.nspname, p.proname, (pg_get_function_arguments(p.oid))
   Sort Method: quicksort  Memory: 43kB
   ->  Hash Join  (cost=1.14..107.61 rows=808 width=138) (actual time=42.495..54.854 rows=71 loops=1)
         Hash Cond: (p.pronamespace = n.oid)
         ->  Seq Scan on pg_proc p  (cost=0.00..89.30 rows=808 width=78) (actual time=0.052..53.465 rows=2402 loops=1)
               Filter: pg_function_is_visible(oid)
         ->  Hash  (cost=1.09..1.09 rows=4 width=68) (actual time=0.011..0.011 rows=4 loops=1)
               Buckets: 1024  Batches: 1  Memory Usage: 1kB
               ->  Seq Scan on pg_namespace n  (cost=0.00..1.09 rows=4 width=68) (actual time=0.005..0.007 rows=4 loops=1)
                     Filter: ((nspname <> 'pg_catalog'::name) AND (nspname <> 'information_schema'::name))

Что бы это могло значить?
Читать дальше →
Всего голосов 33: ↑31 и ↓2 +29
Просмотры 42K
Комментарии 23

Объясняя необъяснимое. Часть 2

Разработка веб-сайтов *PostgreSQL *SQL *
Перевод
Регистрация на конференцию PG Day’16 в разгаре, а мы продолжаем публиковать перевод статей Hubert Lubaczewski об explain и его основных компонентах.

В прошлый раз я писал о том, что показывает вывод explain. Теперь я хочу больше поговорить о разных типах «узлов» / операций, которые вы можете встретить в планах explain.

Читать дальше →
Всего голосов 28: ↑27 и ↓1 +26
Просмотры 40K
Комментарии 4

Объясняя необъяснимое. Часть 3

Разработка веб-сайтов *PostgreSQL *SQL *
Перевод
В рамках подготовки к конференции PG Day’16 мы продолжаем знакомить вас с интересными аспектами PostgreSQL. И сегодня предлагаем вам перевод третьей статьи из серии об explain.

В предыдущих постах этой серии я писал о том, как интерпретировать отдельно взятую строку в выводе анализа explain, его структуру, а также описал базовые операции получения данных (узлы дерева explain).

Сегодня мы перейдем к более сложным операциям.


Читать дальше →
Рейтинг 0
Просмотры 22K
Комментарии 0

Объясняя необъяснимое. Часть 4

Разработка веб-сайтов *PostgreSQL *SQL *
Перевод
Конференция PG Day’16 с каждым днем всё ближе, а мы продолжаем публиковать серию статей Hubert Lubaczewski об анализе explain и его основных операциях.

В этом, надеюсь, предпоследнем посте серии я расскажу об оставшихся наиболее распространенных операциях, которые вы можете встретить в выводе explain.


Читать дальше →
Всего голосов 16: ↑15 и ↓1 +14
Просмотры 16K
Комментарии 4

Объясняя необъяснимое. Часть 5

Разработка веб-сайтов *PostgreSQL *SQL *
Перевод
Мы продолжаем готовиться к PG Day’16 и знакомить вас с интересными возможностями PostgreSQL.

В предыдущих постах этой серии я говорил о том, как читать вывод EXPLAIN и что означает каждая строка (операция/узел).

В заключительном посте я постараюсь объяснить, почему Постгрес выбирает «Операцию X», а не «Операцию Y».


Читать дальше →
Всего голосов 30: ↑28 и ↓2 +26
Просмотры 17K
Комментарии 3

Основы индексирования и возможности EXPLAIN в MySQL

Блог компании Конференции Олега Бунина (Онтико) Высокая производительность *Разработка веб-сайтов *PHP *MySQL *


Темой доклада Василия Лукьянчикова является индексирование в MySQL и расширенные возможности EXPLAIN, т.е. нашей задачей будет ответить на вопросы: что мы можем выяснить с помощью EXPLAIN'а, на что следует обращать внимание?


Многие ограничения EXPLAIN'а связаны с оптимизатором, поэтому мы предварительно посмотрим на архитектуру, чтобы понять, откуда следуют ограничения и что, в принципе, с помощью EXPLAIN'а можно сделать.


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


Доклад, таким образом, состоит из 3х частей:


  • Архитектура;
  • Основы индексирования;
  • EXPLAIN (примеры).

Читать дальше →
Всего голосов 30: ↑30 и ↓0 +30
Просмотры 26K
Комментарии 3

Как писать кривые запросы с неоптимальным планом и заставить задуматься СУБД

MySQL *PostgreSQL *
Всё просто. Тут можно найти «Основы разбора запросов для чайников» в случае PostgreSQL и замечательные невыдуманные примеры из продакшена о том, как не надо писать запросы на PostgreSQL и MySQL и что бывает, если их так всё-таки писать.

Ознакомиться с подробностями
Всего голосов 30: ↑26 и ↓4 +22
Просмотры 17K
Комментарии 24

Снова о деревьях

PostgreSQL *
Из песочницы
Весна, пора подумать о деревьях. Деревья в реляционных — DB это один из самых острых вопросов при работе с данными. В данном топике сравним быстродействие Materialized Path и Adjacency List методов с помощью команды «explain analize».
Читать дальше →
Всего голосов 17: ↑17 и ↓0 +17
Просмотры 9.2K
Комментарии 18

О чем молчит EXPLAIN, и как его разговорить

Блог компании Тензор PostgreSQL *Администрирование баз данных *
Из песочницы
Классический вопрос, с которым разработчик приходит к своему DBA или владелец бизнеса — к консультанту по PostgreSQL, почти всегда звучит одинаково: «Почему запросы выполняются на базе так долго?»

Традиционный набор причин:

  • неэффективный алгоритм
    когда вы решили сделать JOIN нескольких CTE по паре десятков тысяч записей
  • неактуальная статистика
    если фактическое распределение данных в таблице уже сильно отличается от собранной ANALYZE'ом в последний раз
  • «затык» по ресурсам
    и уже не хватает выделенных вычислительных мощностей CPU, постоянно прокачиваются гигабайты памяти или диск не успевает за всеми «хотелками» БД
  • блокировки от конкурирующих процессов

И если блокировки достаточно сложны в поимке и анализе, то для всего остального нам достаточно плана запроса, который можно получить с помощью оператора EXPLAIN (лучше, конечно, сразу EXPLAIN (ANALYZE, BUFFERS) ...) или модуля auto_explain.

Но, как сказано в той же документации,
«Понимание плана — это искусство, и чтобы овладеть им, нужен определённый опыт, …»
Но можно обойтись и без него, если воспользоваться подходящим инструментом!
Читать дальше →
Всего голосов 38: ↑38 и ↓0 +38
Просмотры 15K
Комментарии 77

PostgreSQL Antipatterns: CTE x CTE

Блог компании Тензор PostgreSQL *SQL *Администрирование баз данных *
По роду деятельности приходится сталкиваться с ситуациями, когда разработчик пишет запрос и думает "база умная, сама со всем справится!"

В некоторых случаях (частично от незнания возможностей БД, частично от преждевременных оптимизаций) такой подход приводит к появлению «франкенштейнов».
Читать дальше →
Всего голосов 10: ↑9 и ↓1 +8
Просмотры 6.7K
Комментарии 13

PostgreSQL Antipatterns: вредные JOIN и OR

Блог компании Тензор PostgreSQL *SQL *Администрирование баз данных *
Бойтесь операций, buffers приносящих…
На примере небольшого запроса рассмотрим некоторые универсальные подходы к оптимизации запросов на PostgreSQL. Пользоваться ими или нет — выбирать вам, но знать о них стоит.
Читать дальше →
Всего голосов 20: ↑20 и ↓0 +20
Просмотры 13K
Комментарии 22

PostgreSQL Antipatterns: статистика всему голова

Блог компании Тензор PostgreSQL *SQL *Администрирование баз данных *
Для выбора наиболее эффективного плана выполнения запроса PostgreSQL пользуется накопленной статистикой о распределении значений данных в целевых таблицах.

Она обновляется с помощью явного запуска команд ANALYZE и VACUUM ANALYZE или в фоновом режиме процессом autovacuum/autoanalyze. Но если статистика не успеет актуализироваться — может произойти беда.

Как такую проблему обнаружить и исправить?
Читать дальше →
Всего голосов 10: ↑10 и ↓0 +10
Просмотры 6.1K
Комментарии 1

PostgreSQL Antipatterns: сизифов JOIN массивов

Блог компании Тензор PostgreSQL *SQL *Администрирование баз данных *
Иногда возникает задача «склеить» внутри SQL-запроса из переданных в качестве параметров линейных массивов целостную выборку с теми же данными «по столбцам».
Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Просмотры 6.9K
Комментарии 6

PostgreSQL Antipatterns: передача наборов и выборок в SQL

Блог компании Тензор PostgreSQL *SQL *Администрирование баз данных *
Периодически у разработчика возникает необходимость передать в запрос набор параметров или даже целую выборку «на вход». Иногда попадаются очень странные решения этой задачи.

Пойдем «от обратного» и посмотрим, как делать не стоит, почему, и как можно сделать лучше.
Читать дальше →
Всего голосов 8: ↑8 и ↓0 +8
Просмотры 8K
Комментарии 4

DBA: вычищаем клон-записи из таблицы без PK

Блог компании Тензор PostgreSQL *SQL *Администрирование баз данных *
Случаются ситуации, когда в таблицу без первичного ключа или какого-то другого уникального индекса по недосмотру попадают полные клоны уже существующих записей.



Например, пишутся в PostgreSQL COPY-потоком значения хронологической метрики, а потом внезапный сбой, и часть полностью идентичных данных приходит повторно.

Как избавить базу от ненужных клонов?
Читать дальше →
Всего голосов 13: ↑13 и ↓0 +13
Просмотры 3.4K
Комментарии 11

PostgreSQL Antipatterns: обновляем большую таблицу под нагрузкой

Блог компании Тензор Высокая производительность *PostgreSQL *SQL *Администрирование баз данных *
Как стоит поступить (а как точно не надо), если в «многомиллионной» активно используемой таблице PostgreSQL нужно обновить большое количество записей — проинициализировать значение нового поля или скорректировать ошибки в существующих записях? А при этом сохранить свое время и не потерять деньги компании из-за простоя.


Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Просмотры 11K
Комментарии 7

DBA: когда пасует VACUUM — чистим таблицу вручную

Блог компании Тензор Высокая производительность *PostgreSQL *SQL *Администрирование баз данных *
VACUUM может «зачистить» из таблицы в PostgreSQL только то, что никто не может увидеть — то есть нет ни одного активного запроса, стартовавшего раньше, чем эти записи были изменены.

А если такой неприятный тип (продолжительная OLAP-нагрузка на OLTP-базе) все же есть? Как почистить активно меняющуюся таблицу в окружении длинных запросов и не наступить на грабли?


Читать дальше →
Всего голосов 21: ↑21 и ↓0 +21
Просмотры 11K
Комментарии 20
1