Индексы таблиц

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

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

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

Проектирование индексов таблиц

Когда кто-то думает о слове "индекс", обычно на ум приходит индекс в конце книги — полный обзор текста в книге и где можно найти ключевые слова и темы. Индекс таблицы в SQL Azure аналогичен индексу в задней части книги. Индекс помогает быстро добраться до строки, которую вы ищете, предоставив базе данных карту расположения. Если вы помните, таблицы хранятся на страницах в базе данных SQL Azure, а индексы помогают базе данных быстро находить нужные данные на этих страницах. Индексы также хранятся на страницах с меткой "Индексные страницы".

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

Создание таблицы без индекса приводит к хранению таблицы в виде структуры кучи; Сортировка данных отсутствует. Представьте сценарий с колодой несортированных карт. Отсутствие индекса отлично подходит для таблицы, которая используется в основном для вставки данных или строк, так как на данный момент нет затрат на поиск по строкам. Если бы у вас была воображаемая колода карт, это было бы как просто добавить карты на вершину кучи; быстро и легко, если вы этого добиваетесь. Но представьте, что пытается искать одну строку в таблице миллионов записей, или отдельную карточку в мнимой куче карточек. По мере роста данных (или кучи карточек) вам потребуется какой-то способ получить информацию и доставить ее пользователю как можно быстрее.

Общие сведения об индексах rowstore

Существует два типа индексов rowstore на основе дисков, которые используются с базой данных SQL Azure: кластеризованными и некластеризованными. Кластеризованные индексы сортируют и хранят строки данных в таблице на основе их значения ключа, как правило, первичного ключа. При записи строки в таблицу с кластеризованным индексом строка сортируется и помещается в хранилище в правильном порядке. Подумайте о словаре или энциклопедии и о том, как добавляется новая статья. Кластеризованный индекс будет сортировать и хранить полные данные строк на правильной странице на диске (помните, как таблицы хранятся на страницах на диске). Так как кластеризованный индекс определяет, как данные будут храниться на диске на странице, в таблице может быть только один кластеризованный индекс. Было бы невозможно сортировать и хранить несколько столбцов на одной странице. Попробуйте отсортировать адресную книгу по фамилии людей и штату, но можно только одно из двух. На самом деле при создании первичного ключа в таблице база данных SQL Azure автоматически создает кластеризованный индекс в таблице.

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

Общие сведения об индексах columnstore

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

Индексы столбцового хранения, как и индексы строкового хранения, бывают кластеризованными и некластеризованными. Как и индексы rowstore, кластеризованный columnstore индекс отсортирует данные при их хранении на странице. Некластеризованный индекс columnstore — это указатель на место хранения строки на странице. Вернитесь к примеру словаря, сравнивая запись слова на странице и индекс в задней части книги. Кластеризованный индекс columnstore будет иметь слова, отсортированные по алфавиту на страницах с определениями и произношением. Некластеризованный индекс columnstore похож на индекс словаря; показывает указатель (номер страницы), где можно найти это слово и определение.

Когда использовать индексирование по столбцам

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

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

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

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

Полнотекстовые индексы

Не будет ли это хорошая функция в приложении с ссылкой на карточки, если пользователь может ввести текст, а затем вернуть все результаты, которые соответствуют? Функция может учитывать опечатки и игнорировать чувствительность регистра? База данных SQL Azure содержит полнотекстовый индекс поиска, позволяющий пользователям и приложениям выполнять полнотекстовые запросы к столбцам на основе символов, которые полезны для столбцов card_name и card_text. Можно применить полнотекстовый индекс к столбцам, имеющим любой из следующих типов данных: char, varchar, nchar, nvarchar, text, ntext, image, xmlили varbinary(max) и FILESTREAM.