Простой select count (id) использует 100% DTU Azure SQL

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

В основном, работает:

select count(id) from mytable

EDIT: добавление предложения where не помогает.

Выполняется от 8 до 30 минут для запуска (тогда как тот же запрос на локальной копии SQL Server занимает около 4 секунд).

Ниже приведен снимок экрана на вкладке MONITOR на портале Azure, когда я запускаю этот запрос. Примечание. Я сделал это после того, как не касался базы данных около недели, а отчеты Azure я использовал только 1% моих DTU.

enter image description here

Несколько дополнительных вещей:

  • В этом конкретном тесте запрос выполнил 08: 27 для запуска.
  • Пока он работал, приведенная выше диаграмма фактически показывала линию DTU на 100% за период.
  • В базе данных настроен стандартный уровень обслуживания с уровнем производительности S1.
  • База данных составляет около 3,3 ГБ, и это самая большая таблица (счет возвращается примерно 2 000 000).

Я ценю, что это может быть просто мое ограниченное понимание, но если кто-то может прояснить, действительно ли это ожидаемое поведение (т.е. простой подсчет, который так долго запускается и максимизирует мои DTU), это было бы очень признательно.

Ответ 1

Из статистики запроса в предыдущем вопросе мы можем видеть:

300ms CPU time
8000 physical reads

8:30 составляет около 500 секунд. Мы, конечно, не связаны с ЦП. 300 мс с процессором более 500 сек практически не используется. Мы получаем 16 физических чтений в секунду. Это намного ниже того, что может предоставить любой физический диск. Кроме того, таблица не полностью кэширована, о чем свидетельствует наличие физического ввода-вывода.

Я бы сказал, что вы дросселированы. S1 соответствует для

934 транзакций в минуту

для некоторого определения транзакции. Thats около 15 trans/sec. Может быть, вы нажимаете лимит на один физический IO за транзакцию?! 15 и 16 являются подозрительно похожими номерами.

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

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

Ответ 2

У меня была такая же проблема. Обновление статистики с помощью fullscan на столе разрешило это:

update statistics mytable with fullscan

Ответ 3

выберите счетчик

должен выполнять кластерное сканирование индексов, если оно доступно и обновлено. Azure SQL автоматически обновляет статистику, но автоматически не обновляет индексы, если они полностью устарели.

если в этой таблице много трафика INSERT/UPDATE/DELETE, я предлагаю вручную перестраивать индексы каждый раз в то время.

http://blogs.msdn.com/b/dilkushp/archive/2013/07/28/fragmentation-in-sql-azure.aspx

и SO post для получения дополнительной информации

SQL Azure и индексы