Показаны сообщения с ярлыком Query Optimisation. Показать все сообщения
Показаны сообщения с ярлыком Query Optimisation. Показать все сообщения

3.4.26

SQL Server Parameter Sniffing: ошибка, которая не является ошибкой (но всё ломает)

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

В этой статье вы узнаете, как выявить и победить нестабильную производительность в SQL Server. Если ваши запросы без предупреждения переходят от «молниеносных» к «еле ползущим», вы стали жертвой Parameter Sniffing. Пришло время вернуть контроль над вашими планами выполнения и остановить непредсказуемость.

Ваш запрос работает быстро, а затем внезапно… становится медленным!
У вас есть:

  • Тот же запрос.
  • Те же данные.
  • Тот же сервер.

👉 Что изменилось?

💣 Parameter Sniffing. И нет… это НЕ ошибка. Это то, как SQL Server был спроектирован для работы.

30.3.26

Ваш план исполнения лжёт Вам...и Вы об этом не догадываетесь

Автор: Luca Biondi, 😈 Your Execution Plan Is Lying to You ...And You Don’t Know It

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

Исполнение плана выглядит идеально…
но ваш запрос всё ещё медленно работает.

👉 Что-то лжёт вам.

И нет… не SQL Server! ....это то, как вы читаете план выполнения.

27.3.26

Перегружена ли индексами ваша база данных?

Автор: Luca Biondi, Is Your Database Over-Indexed? Your Indexes Might Be Killing Performance

👉 Если вы пропустили мою предыдущую статью, ознакомьтесь с ней здесь: Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction

Ваш запрос работает медленно.
И вы добавляете индекс.

Запрос ускоряется… на мгновение.

Но затем всё остальное начинает работать медленнее.

👉 Что же произошло?

Возможно, вы перегружаете свою базу данных индексами.

25.3.26

Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction

Автор: Luca Biondi, Stop Defragmenting indexes: Auto Index Compaction feature preview in SQL Server – This Feature will Kills Index Maintenance Jobs!

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

👉 Если вы пропустили, посмотрите здесь:
SQL Server 2025 CU3 – Скрытое улучшение производительности, о котором никто не говорит

В этой же статье мы представим удивительную новость в мире SQL Server, которую я называю функцией автоматического уплотнения индексов (Auto Index Compaction).

22.3.26

Самая распространённая ошибка индексирования в SQL Server (и как её исправить)

Автор: Luca Biondi, The Most Common SQL Server Indexing Mistake (And How to Fix It)

Индексы — одна из самых мощных функций производительности в SQL Server. Но они также одни из самых непонятых. Многие разработчики считают, что добавление новых индексов автоматически улучшает производительность. К сожалению, часто бывает наоборот. Одна из самых распространённых проблем с производительностью SQL Server, которую я вижу в реальных системах, — это база данных, полная ненужных или плохо спроектированных индексов. Сегодня мы рассмотрим самую распространённую ошибку индексирования в SQL Server и способ её исправления.

17.3.26

Как удалось убрал 32 секунды из запроса без добавления индекса

Автор: Luca Biondi, I Removed 32 Seconds From This SQL Server Query ...Without Adding an Index! Part 7

Это не теория.
Это не лабораторная настройка.
Это произошло с реальной рабочей нагрузкой.

Исходное время выполнения: 42 секунды.
После оптимизации: 9.8 секунды.

Никакого нового индекса.
Никакого изменения схемы.
Никакого обновления оборудования.

Просто понимание того, как работает движок.

Приятного чтения — давайте заставим SQL Server летать.

Продолжение серии статей, вот предыдущая: Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)

16.3.26

Стратегии индексирования для производительности SQL Server

Автор: Paul Randal, SQL101: Indexing Strategies for SQL Server Performance

Один из самых простых способов повысить производительность запросов в SQL Server — обеспечить быстрый доступ к запрашиваемым данным, причём максимально эффективно. В SQL Server использование одного или нескольких индексов может стать именно тем решением, которое вам нужно. Фактически, индексы настолько важны, что SQL Server может даже предупредить вас, когда обнаружит, что отсутствует индекс, который был бы полезен для запроса. Это обзорная статья объяснит, что такое индексы, почему они так важны, а также немного об искусстве и науке разработки различных стратегий индексирования.

15.3.26

Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)

Автор: Luca Biondi, Still on Batch Mode… – Part 6: Compatibility & Query Settings That Influence Execution

Назад к серии: Как указать Batch Mode для Rowstore, если его нет в плане (Часть 5)

Мы всё ещё говорим о пакетном режиме, потому что понимание того, когда он работает, так же важно, как и знание того, как его принудительно включить.

Сегодня мы углубимся: мы рассмотрим уровни совместимости, выделение памяти, оценку количества строк и флаги трассировки.

Приятного чтения, и пусть ваш CPU остаётся холодным при тяжёлых агрегатах!

12.3.26

Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)

Автор: Luca Biondi, SQL Server: No New Index. No Schema Changes. 10x Faster Queries – SQL Server Batch Mode on Rowstore Deep Dive!! Part 4!

Надеюсь, вам нравится эта серия. Я искренне верю, что она может быть очень полезной для тех, кто профессионально использует SQL Server, как это делаю я уже более 20 лет (как летит время!).

Сегодня мы поговорим о пакетном режиме для строчного хранения (Batch Mode on Rowstore) и о том, как сделать ваш запрос в 10 раз быстрее без добавления каких-либо индексов.

Что ж... в Части 3 мы представили колоночные индексы и увидели, как выполнение в пакетном режиме может кардинально улучшить аналитические запросы.

Если вы пропустили предыдущую часть, вы можете прочитать её здесь:

👉 Фильтрованный индекс против индексированного представления и индекса с хранением в колонках (Часть 3)

Но вот в чём поворот.

Начиная с SQL Server 2019, вам не всегда нужен колоночный индекс, чтобы получить производительность пакетного режима.

SQL Server может активировать пакетный режим для строчного хранения.

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

11.3.26

Логические чтения не повторяемы на колоночных индексах (эх...)

Автор: Brent Ozar, Logical Reads Aren’t Repeatable on Columnstore Indexes. (sigh)

Иногда я действительно ненавижу свою работу.

Вечно, ВЕЧНО, я мог утверждать: «Когда вы измеряете производительность хранилища во время настройки индексов и запросов, вы всегда должны использовать логические чтения, а не физические, потому что логические чтения повторяемы, а физические — нет. Физические чтения могут меняться в зависимости от того, что находится в кэше, какие другие запросы выполняются в данный момент, от редакции вашего SQL Server и от того, используются ли упреждающие чтения. Логические чтения просто отражают точное количество прочитанных страниц, независимо от того, откуда пришли данные (с диска или из кэша), так что пока это число уменьшается, вы делаете свою работу хорошо».

10.3.26

Фильтрованный индекс против индексированного представления и индекса с хранением в колонках (Часть 3)

Автор: Luca Biondi, SQL Server, Filtered Index vs Indexed View vs Columnstore Index! Part 3

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

Если вы пропустили Часть 2, вы можете прочитать её здесь:

👉 Фильтрованные индексы: сравнение производительности с примерами (Часть 2)

Сегодня мы добавляем в игру нового игрока.

Потому что, когда объём данных начинает расти… когда миллионы строк превращаются в десятки или сотни миллионов… мы получаем мощного нового союзника:

Колоночные индексы (Columnstore Indexes).

И это меняет всё.

8.3.26

Фильтрованные индексы: сравнение производительности с примерами (Часть 2)

Автор: Luca Biondi, Filtered Index vs Indexed View in SQL Server: Complete Performance Comparison with Real Examples

Эта статья является продолжением предыдущего глубокого погружения в настройку производительности SQL Server!

Если вы пропустили Часть 1, вы можете прочитать её здесь:

Как фильтрованные индексы кардинально улучшают производительность запросов (часть 1)

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

Сегодня мы углубляемся и сравниваем фильтрованный индекс с индексированным представлением, используя практические, воспроизводимые SQL-скрипты.

Вы найдёте конкретные сценарии, которые сможете протестировать в своей собственной лаборатории — потому что настройка производительности — это не теория, это экспериментирование.

27.2.26

Как фильтрованные индексы кардинально улучшают производительность запросов (часть 1)

Автор: Luca Biondi, SQL Server Performance Tuning: How Filtered Indexes Drastically Improve Query Performance

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

Если вы работаете с Microsoft SQL Server и боретесь с медленными запросами, высокими логическими чтениями или неэффективными планами выполнения, эта продвинутая техника настройки производительности SQL Server может кардинально улучшить производительность запросов.

В этой статье мы проанализируем, как фильтрованные индексы в SQL Server могут уменьшить ввод-вывод, оптимизировать планы выполнения и значительно повысить производительность OLTP.

25.2.26

Как оптимизировать переключение реплик групп доступности SQL Server

Автор: Aaron Bertrand , Serializing Deletes From Clustered Columnstore Indexes

Мы часто выполняем плановые переключения реплик в группах доступности SQL Server для обслуживания, установки исправлений, обновлений и даже ротации оборудования. Обычно наши переключения выполняются быстро, но иногда они занимают больше времени — и не всегда интуитивно понятно почему, поскольку нет очевидной связи со временем суток, размером базы данных или объёмом транзакций.

Сокращение даже нескольких секунд из этого процесса может улучшить взаимодействие с приложением и конечным пользователем; это также может значительно снизить количество оповещений или, по крайней мере, сократить время, в течение которого оповещения должны быть отключены. Существует множество материалов о том, как правильно выполнять переключения в AG (без потери данных), но гораздо меньше тех, которые сосредоточены на сокращении окна прерывания доступности. Разница обычно заключается в некоторой комбинации объёма повторного выполнения (redo), поведения контрольных точек, открытых транзакций и готовности вторичной реплики.

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

17.2.26

Любопытный случай периодического сбоя запроса к крошечной таблице

Автор: Paul Randal, The Curious Case of… occasional query failure on a tiny table

Это случай, произошедший в прошлом году в системе одного клиента: иногда обычный запрос к крошечной таблице, казалось, «зависал», и его приходилось убивать и запускать заново. В чём же дело?

Рассматриваемая таблица содержала всего несколько миллионов строк данных с максимальным размером строки 60 байт, и запрос обычно выполнялся за несколько секунд, но иногда он «зависал» и либо его приходилось убивать, либо он выполнялся десятки минут. Диагностические средства, запущенные во время возникновения проблемы, не показывали каких-либо необычных ожиданий, давления на сервер не было, а план запроса, генерируемый при долгом выполнении, был практически таким же.

9.2.26

Оптимизация базы данных для нерегламентированных запросов

Автор: Joe Sack, Database scoped optimizing for ad hoc workloads

SQL Server предоставляет параметр оптимизации для нерегламентированных рабочих нагрузок (ad-hoc workloads), действующий в рамках всего сервера, который используется для уменьшения объёма памяти, занимаемого одиночными ad-hoc пакетами и связанными с ними планами. Когда этот параметр включён на уровне экземпляра SQL Server, при первом выполнении пакета ad-hoc для любой базы данных на экземпляре сохраняется «заглушка» скомпилированного плана с уменьшенным потреблением памяти. Эта опция сервера OPTIMIZE_FOR_AD_HOC_WORKLOADS доступна начиная с SQL Server 2019, и имет область действия на уровне базы данных.

8.2.26

Большое количество планов выполнения для одного запроса

Автор: Jose_Manuel_Jurado, Lesson Learned #494: High number of Executions Plans for a Single Query

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

7.2.26

Sniffing параметров в SQL Server

Автор: Vivek Johari, Parameter Sniffing in SQL Server

"Parameter Sniffing" (конфиденциальность параметров) в SQL Server происходит, когда план выполнения запроса генерируется с использованием конкретных значений параметров. Последующие выполнения того же запроса могут работать плохо с другими значениями параметров из-за неподходящего кэшированного плана. Вот как можно решить эту проблему:

6.2.26

Принудительные планы в SQL Server перезаписывают хэш запроса

Автор: Paul White, SQL Server Forced Plans Overwite the Query Hash

Если вы «принудительно» задаёте план, любым методом, включая руководство планом (Plan Guides), хранилище запросов (Query Store) и автоматическое исправление плана (Automatic Plan Correction), результирующий план будет иметь свой query_hash перезаписанным значением query_plan_hash.

Другими словами, хэш плана и хэш плана запроса получат значение хэша плана запроса. Реальное значение хэша запроса просто теряется. 🤦

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