Индексы и все, все, все (Часть 1)

• Андрей приветствует участников вебинара и объявляет о начале встречи.  

• Андрей представляет докладчика, Дмитрия Короткевича, который будет говорить об индексах.  

• Дмитрий рассказывает о сообществе, которое работает под эгидой Паз, и о предстоящих конференциях.  

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

• Дмитрий разделяет системы на онлайн-транзакшн и хаос-системы, объясняя их особенности и различия.  

• Он также упоминает о том, что будет говорить об индексах в контексте онлайн-транзакшн систем.  

• Дмитрий объясняет, как сиквел сервер работает с таблицами без первичных ключей и кластерных индексов, и как он оценивает занятое место на страницах.  

• Он также объясняет, как сервер выбирает, на какую страницу записывать данные, ориентируясь на процент заполнения страницы.  

• В видео рассказывается о работе с индексами в SQL Server.  

• Создается таблица с 20 записями, каждая запись занимает чуть больше 4000 байт.  

• В результате, таблица занимает чуть больше 50% свободного места на странице.  

• При добавлении новой записи, которая занимает больше 20% свободного места на странице, SQL Server создает новую страницу.  

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

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

• Это уменьшает количество операций ввода-вывода при чтении данных из таблицы.  

• При увеличении размера записей и их частом обновлении, количество указателей увеличивается, что приводит к увеличению количества операций ввода-вывода.  

• Это может негативно сказаться на производительности системы.  

• Вторая проблема с хип-таблицами связана с не оптимальным контролем свободного места.  

• Если записи большие, то теряется много места на страницах.  

• Для решения этой проблемы можно использовать свободное место на страницах или пересоздание таблицы.  

• Кластерный индекс сортирует данные в таблице по значению ключа.  

• Он отвечает за сортировку данных и создание двунаправленного списка страниц.  

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

• Структура записи на каждом уровне состоит из физического адреса страницы и минимального значения ключа.  

• Кластерный индекс имеет корневой уровень, который является точкой входа в индекс.  

• Количество уровней в индексе зависит от размера записей, размера ключа и количества страниц на уровне листьев.  

• Сервер использует три способа использования индексов: сканирование, отсортированное сканирование и сканирование карты использования индекса.  

• Сканирование начинается с корневой страницы индекса и заканчивается последней страницей, читая записи друг за другом.  

• Отсортированное сканирование использует сортировку кластерного ключа для чтения записей в порядке их записи.  

• Сервер использует карту использования индекса для сканирования записей из таблицы в порядке, указанном в карте.  

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

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

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

• Поиск позволяет серверу найти запись с минимальным или максимальным значением ключа в индексе.  

• Сарго был предикаты позволяют серверу использовать поиск в индексах, если они определены.  

• Сарго был предикаты могут быть использованы для выбора одной или нескольких записей из индекса.  

• Сервер может использовать поиск по индексам только для определенных типов данных.  

• При использовании строковых параметров, сервер может использовать сканирование вместо поиска.  

• При использовании юникодных параметров, сервер может использовать поиск по индексу.  

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

• Если предикат на левом поле индекса является саго, то сервер может использовать этот индекс для поиска независимо от предикатов на других полях.  

• Не кластерные индексы содержат отсортированные данные и используются для поиска по определенным значениям.  

• Если данные в таблице уникальные, рекомендуется определять индексы как уникальные.  

• Сервер использует алгоритм прохода по дереву индекса для поиска данных.  

• Если найдено большое количество записей, сервер может выполнить много операций ввода-вывода.  

• В примере создается таблица с уникальным кластерным индексом и некластерным индексом на поле "реб".  

• Сервер сканирует кластерный индекс для подсчета числа записей, что требует чтения 31 тысячи страниц.  

• В видео обсуждается использование некластерных индексов в SQL Server.  

• Если индекс используется для поиска по префиксу, то сервер использует операцию поиска по некластерному индексу.  

• Если индекс используется для чтения записей, то сервер использует операцию килукап.  

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

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

• Создание индекса на поле пол студента может быть неэффективным, если сервер не знает, сколько мужчин и женщин в таблице.  

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

• SQL Server использует статистику для оценки количества операций чтения при сканировании таблицы или использовании некластерного индекса.  

• Статистика автоматически создается при создании индекса.  

• Команда "show statistics" позволяет просмотреть статистику по индексу.  

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

• Третий результат - гистограмма, которая хранит значения ключа и информацию о том, что творится с этими значениями в разных интервалах.  

• Статистику не обновляется автоматически, если количество записей в таблице изменилось на 20%.  

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

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

• Будьте осторожны с большими таблицами и неравномерным распределением данных.  

• Используйте флаг 2371 для более динамического пересчета статистики.  

• Нал поля используются для навигации по кластерному индексу, но не используются для вычисления минимального значения ключа.  

• Количество уровней в индексе зависит от количества страниц на уровне листьев.  

• Сервер хранит количество изменений данных внутри статистики.  

• Статистика обновляется автоматически или синхронно.  

• При автоматическом обновлении статистика обновляется при выполнении запроса.  

• При синхронном обновлении статистика обновляется после выполнения запроса.  

• Пересоздание таблицы с кластерным индексом и пересоздание кластерного индекса - одна и та же операция.  

• Оптимизация поиска по таблице связана с обновлением статистики, а не с пересозданием таблицы.  

• При изменении статистики в SQL Server, сервер сканирует определенные диапазоны индекса в зависимости от количества строк.  

• Сервер может указать, какие части данных должны быть отсканированы.  

• При изменении статистики, сервер использует промежуточные уровни и выборки по индексу для построения дистограммы.  

• При записи данных, сервер синхронно записывает данные в журнал транзакции.  

• После изменения записи, сервер меняет страницу в памяти и записывает изменения в журнал базы данных.  

• При задании условий поиска по индексу, сервер будет искать данные, начиная с указанного поля.  

• Если индекс состоит из нескольких полей, поиск будет выполняться по всем указанным полям.  

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

• Вертикальные индексы не модифицируются, добавление новых секций возможно.  

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

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

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

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

• Компрессия на уровне столбцов просто меняет формат столбца, а компрессия на уровне страниц похожа на реальное архивирование.  

• Если у вас данные редко доступны и редко меняются, компрессия может помочь уменьшить нагрузку на процессор и систему вывода.  

• Если у вас есть дополнительные вопросы по этим темам, можно написать автору по электронной почте.  

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

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

• Материалы с предыдущих встреч будут доступны на сайте.