У меня очень большая таблица в базе данных Azure SQL, которая уже имеет более 30 миллионов строк и имеет много вставок, выполняемых в таблице каждый день ~ 50-60k
У нас есть разные страницы в веб-приложении, которым нужны данные из этой большой таблицы ... каждая страница имеет свой способ запроса этой таблицы с точки зрения того, какие столбцы требуются и какие столбцы упомянуты в предложении where.
Поскольку база данных находится на лазурном уровне, некоторые индексы были автоматически применены лазером, глядя на выполняемые запросы, которые теперь вызывают проблемы с производительностью, поскольку размер базы данных очень велик. Используя dmv в SQL, я обнаружил, что размер данных составляет около 15 ГБ, но индекс почти 65 ГБ
Как в этом случае создать эффективные индексы?
Вам следует использовать некластеризованный индекс, который поможет быстрее искать данные.





Брентозар опубликовал свой бесплатный сценарий, который выполняет хороший анализ, например:
На основе приведенного выше сценария можно сделать вывод, какие индексы следует отбросить в базе данных SQL Azure.
Как сообщает MSDN, можно удалить индексы в базе данных SQL Azure.
Индексы, созданные с помощью автоматической настройки, не снижают производительность вашей базы данных, однако отсутствие регулярной дефрагментации индексов и регулярного обновления статистики базы данных, несомненно, может способствовать снижению производительности. Кроме того, фрагментация индекса может увеличить размер базы данных, как объяснялось здесь, что является одним из симптомов, упомянутых вами выше. Выполните задачу обслуживания, как объяснено здесь.
Вы подсчитываете кластерные индексы в размере индекса? Поскольку этот индекс хранит данные, он не должен считаться размером «индекса». Это должны быть только все остальные типы индексов (некластеризованный, некластеризованный columnstore и т. д.).
Создание эффективных индексов всегда связано с основами настройки запросов. Во-первых, определите запросы, которые выполняются медленно. Во-вторых, посмотрите на код и план выполнения, чтобы понять, что делает запрос и почему он может выполняться медленно. Чаще всего проблема не в индексах, а в коде. Затем, в зависимости от того, что вы найдете в коде и плане выполнения, сначала исправьте код, а во-вторых, создайте или измените индексы для поддержки кода. Убедитесь, что вы измеряете производительность запроса до изменений и после, чтобы убедиться, что изменения приводят к улучшениям.
Кроме того, база данных SQL Azure не обслуживает статистику. Вы должны это настроить. Некоторые из ваших статистических данных могут потребовать особой любви и заботы. Вам нужно будет изучить их более подробно, чтобы определить те, которые устаревают без обновления, или те, которые нуждаются в полном обновлении сканирования, по сравнению с теми, для которых необходимо выполнить выборку (и размер выборки).
Короче говоря, настройка производительности База данных SQL Azure в основном такая же, как настройка производительности любой другой базы данных SQL Server.
Вы рассматривали уровень кеширования? Каждая страница не должна попадать напрямую в базу данных при каждом чтении.