SQL-Ex blog

Пересказ статьи Erik Darling. The How To Write SQL Server Queries Correctly Cheat Sheet: EXISTS and NOT EXISTS

Замечательная вещь, связанная с SQL, состоит в том, что имеется много директив, которые довольно легко понять и использовать по назначению.

Ужасная вещь, относящаяся к SQL, заключается в том, что в нем столько же правил, которые применяются избирательно, как и в самом английском языке.

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

Очень немного людей идут в магазин выбирать (select) молоко, яйца, масло, соль, перец и виски. Большинство из нас просто идет взять (get) их. Но хватит о завтраке.

Давайте поговорим о двух наиболее часто упускаемых из виду и недооцененных возможностях в языке SQL: EXISTS и NOT EXISTS. Возможно, они бы больше привлекали внимание, если бы назывались THERE and NOT THERE, но тогда была бы опасность начального затруднения с предложениями WHERE и THERE.

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

Хотя они несколько напоминают подзапросы, столбцы, которые вы выбираете в подзапросе EXISTS или NOT EXISTS не могут использоваться во внешнем запросе. Вы можете поместить что угодно в список SELECT, от * или 1 до COUNT или 1/0, или всего содержимого Библии короля Якова, и это никогда не приведет ни к каким даже самым незначительным изменениям в мире. Аналогично, добавление DISTINCT, TOP или любого другого ограничителя числа строк не сделает ничего такого, чтобы изменить план запроса или его производительность.

Преодолейте себя.

И EXISTS, и NOT EXISTS уже установили число строк в 1, поскольку все, что нужно сделать каждому из них, это определить, существует хотя бы одна строка или нет, и наоборот.
Continue reading "Шпаргалка по правильному написанию запросов к SQL server: EXISTS и NOT EXISTS"

Пересказ статьи Semab Tariq. PostgreSQL Internals Part 2: Understanding Page Structure

Это вторая статья данной серии. В первой части мы рассмотрели кластеры баз данных и их физическую структуру.

Во второй части мы изучим внутреннюю структуру страницы в PostgreSQL. Первую часть вы можете найти здесь.

Обзор макета страницы в PostgreSQL

При создании таблицы генерируется соответствующий файл данных. Внутри этого файла данные размещаются на страницах фиксированной длины, обычно 8-килобайтных, что принимается по умолчанию. Каждой странице присваивается последовательный номер, начиная с 0, который называется номером блока. PostgreSQL добавляет новую пустую страницу к концу файла, когда он заполняется. Тем самым увеличивается размер файла данных.
Continue reading "PostgreSQL изнутри. Часть 2: понимание структуры страницы"

Пересказ статьи Dmitry Romanoff. PostgreSQL. How do you find potentially ineffective indexes?

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

Наличие слишком большого числа индексов на таблице PostgreSQL может оказать негативное влияние на производительность базы данных и потребление ресурсов.

Следующий запрос поможет вам найти потенциально неэффективные индексы.
Continue reading "PostgreSQL. Как обнаружить потенциально неэффективные индексы?"

Пересказ статьи Dileep kumar. PostgreSQL -Row level & Table level Locks

Пессимистичные блокировки в PostgreSQL

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

Что такое блокировка

В мире баз данных блокировка является логическим объектом, который упорядочивает доступ к данным, когда два или более пользователей пытаются получить доступ к одним и тем же данным. Являясь развитой СУБД, PostgreSQL предоставляет несколько механизмов блокирования для обработки конкурентных запросов, что в конечном итоге обеспечивает большую согласованность данных.

В последующих разделах рассматриваются блокировки уровня строки, таблицы, сессии и транзакции.

Continue reading "PostgreSQL - блокировки уровня строки и уровня таблицы"

Пересказ статьи Erik Darling. Indexing SQL Server Queries For Performance: Fixing Windowing Functions

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

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

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

Я хочу вам показать ограниченность индексирования для решения проблем производительности ранжирующих оконных функций в построчном режиме (Row Mode). Это особенно болезненно для разработчиков, вынужденных использовать Standard Edition, где пакетный режим безнадежно канул в Лету.

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

Конечно, есть множество вещей, которые делают другие оконные функции и которые простым переписыванием запросов не охватываются.

Вот несколько примеров: Continue reading "Индексация запросов SQL Server для производительности: исправление оконных функций"

Пересказ статьи Brent Ozar. Does Your GROUP BY Order Matter?

Иногда, когда вы используете GROUP BY, порядок столбцов имеет значение. Например, эти два запроса SELECT дают разные результаты:

CREATE INDEX Location_DisplayName

  ON dbo.Users(Location, DisplayName);



SELECT TOP 100 Location, DisplayName, COUNT(*) AS Duplicates

FROM dbo.Users

GROUP BY Location, DisplayName

ORDER BY Location, DisplayName;



SELECT TOP 100 DisplayName, Location, COUNT(*) AS Duplicates

FROM dbo.Users

GROUP BY DisplayName, Location

ORDER BY DisplayName, Location;

Их действительные планы выполнения существенно разнятся:

Continue reading "Имеет ли значение порядок в GROUP BY?"