Перевод статьи подготовлен в преддверии старта курса «MS SQL Server Developer».

---

Может ли запрос, выполняющийся параллельно, использовать меньше CPU и выполняться быстрее, чем такой же запрос, выполняющийся последовательно?



Да! Для демонстрации я буду использовать две таблицы с одной колонкой типа integer.





Примечание — TSQL скрипт в виде текста находится в конце статьи. Читать дальше →

https://habr.com/ru/post/516996/?utm_source=habrahabr&utm_medium=rss&utm_campaign=516996

Продолжение статьи Руководство по SQL: Как лучше писать запросы (Часть 1)

От запроса к планам выполнения

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



Следует также отметить, что некоторые из антипаттернов, упомянутых в последнем разделе, коренятся в проблемах производительности, таких, как операторы AND, OR и NOT и их отсутствие при использовании индексов. Размышление о производительности требует не только более структурированного, но и более глубокого подхода.



Однако этот структурированный и углубленный подход будет в основном основан на плане запроса, который, как вы помните, является результатом запроса, впервые проанализированного в «дерево синтаксического анализа» или «дерево разбора» («parse tree»), и точно определяет, какой алгоритм используется для каждой операции и как координируется их выполнение.
Читать дальше ->

https://habr.com/ru/post/465975/?utm_source=habrahabr&utm_medium=rss&utm_campaign=465975

Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

Язык структурированных запросов (SQL) является незаменимым навыком в индустрии информатики, и вообще говоря, изучение этого навыка относительно просто. Однако большинство забывают, что SQL — это не только написание запросов, это всего лишь первый шаг дальше по дороге. Обеспечение производительности запросов или их соответствия контексту, в котором вы работаете, — это совсем другая вещь.



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

• Во-первых, вы начнете с краткого обзора важности обучения SQL для работы в области науки о данных;


• Далее вы сначала узнаете о том, как выполняется обработка и выполнение запросов SQL, чтобы понять важность создания качественных запросов. Конкретнее, вы увидите, что запрос анализируется, переписывается, оптимизируется и окончательно оценивается.


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


• Вы также увидите, что эти антипаттерны вытекают из проблем производительности и что, помимо «ручного» подхода к улучшению SQL-запросов, вы можете анализировать свои запросы также более структурированным, углубленным способом, используя некоторые другие инструменты, которые помогают увидеть план запроса; И,


• Вы вкратце узнаете о time complexity и big O notation, для получения представления о сложности плана выполнения во времени перед выполнением запроса;


• Вы кратко узнаете о том, как оптимизировать запрос.

Читать дальше ->

https://habr.com/ru/post/465547/?utm_source=habrahabr&utm_medium=rss&utm_campaign=465547

В прошлой статье об инструменте для мониторинга Foglight for Databases мы рассказывали о возможностях контроля из единого интерфейса SQL Server, Oracle, PostgreSQL, MySQL, SAP ASE, DB2, Cassandra и MongoDB. Сегодня разберём подходы к быстрому выявлению причин нештатной работы Microsoft SQL Server:

• Поиск источника блокировки;


• Сравнение настроек БД «было-стало» с привязкой к метрикам производительности;


• Поиск изменений в структуре БД, из-за которых снизилась производительность.

Подробности под катом.
Читать дальше ->

https://habr.com/ru/post/464963/?utm_source=habrahabr&utm_medium=rss&utm_campaign=464963

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



Обычный день, обычный релиз: все задачи вдоль и поперек проверены нашим QA-инженером, поэтому со спокойствием священной коровы «закатываем» на stage. Приложение ведет себя хорошо, в логах — тишина. Принимаем решение делать switch (stage <-> prod). Переключаем, смотрим на приборы…



Проходит пару минут, полет стабильный. QA-инженер делает smoke-тест, замечает, что приложение как-то неестественно подтормаживает. Списываем на прогрев кешей.



Проходит еще пару минут, первая жалоба из первой линии: у клиентов очень долго загружаются данные, приложение тормозит, долго отвечает и т.д. Начинаем беспокоиться… смотрим логи, ищем возможные причины.
Читать дальше ->

https://habr.com/ru/post/454066/?utm_source=habrahabr&utm_medium=rss&utm_campaign=454066