Pull to refresh
  • by relevance
  • by date
  • by rating

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

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

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

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

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

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

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

Рассмотрим пример.
Читать дальше →
Total votes 71: ↑68 and ↓3 +65
Views 3.9K
Comments 61

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

Website development *PostgreSQL *SQL *
Translation
Друзья, мы с радостью продолжаем публикацию интересных материалов, посвященных самым разнообразным аспектам работы с 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))

Что бы это могло значить?
Читать дальше →
Total votes 33: ↑31 and ↓2 +29
Views 42K
Comments 23

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

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

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

Читать дальше →
Total votes 28: ↑27 and ↓1 +26
Views 39K
Comments 4

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

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

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

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


Читать дальше →
Rating 0
Views 22K
Comments 0

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

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

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


Читать дальше →
Total votes 16: ↑15 and ↓1 +14
Views 16K
Comments 4

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

Website development *PostgreSQL *SQL *
Translation
Мы продолжаем готовиться к PG Day’16 и знакомить вас с интересными возможностями PostgreSQL.

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

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


Читать дальше →
Total votes 30: ↑28 and ↓2 +26
Views 17K
Comments 3

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

Конференции Олега Бунина (Онтико) corporate blog High performance *Website development *PHP *MySQL *


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


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


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


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


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

Читать дальше →
Total votes 30: ↑30 and ↓0 +30
Views 26K
Comments 3

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

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

Ознакомиться с подробностями
Total votes 30: ↑26 and ↓4 +22
Views 17K
Comments 24

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

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

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

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

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

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

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

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

PostgreSQL Antipatterns: CTE x CTE

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

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

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

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

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

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

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

Как такую проблему обнаружить и исправить?
Читать дальше →
Total votes 10: ↑10 and ↓0 +10
Views 6K
Comments 1

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

Тензор corporate blog PostgreSQL *SQL *Database Administration *
Иногда возникает задача «склеить» внутри SQL-запроса из переданных в качестве параметров линейных массивов целостную выборку с теми же данными «по столбцам».
Читать дальше →
Total votes 14: ↑14 and ↓0 +14
Views 6.9K
Comments 6

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

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

Пойдем «от обратного» и посмотрим, как делать не стоит, почему, и как можно сделать лучше.
Читать дальше →
Total votes 8: ↑8 and ↓0 +8
Views 7.9K
Comments 4

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

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



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

Как избавить базу от ненужных клонов?
Читать дальше →
Total votes 13: ↑13 and ↓0 +13
Views 3.4K
Comments 11

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

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


Читать дальше →
Total votes 14: ↑14 and ↓0 +14
Views 11K
Comments 7

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

Тензор corporate blog High performance *PostgreSQL *SQL *Database Administration *
VACUUM может «зачистить» из таблицы в PostgreSQL только то, что никто не может увидеть — то есть нет ни одного активного запроса, стартовавшего раньше, чем эти записи были изменены.

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


Читать дальше →
Total votes 21: ↑21 and ↓0 +21
Views 11K
Comments 20
1