Безумно низкая производительность запросов в SQL Azure - PullRequest
3 голосов
/ 10 марта 2019

У нас есть S1: 20 DTU, 250 ГБ, база данных SQL Azure со следующей таблицей

CREATE TABLE [dbo].[Reads]
(
    [ReadId] [INT] IDENTITY(1,1) NOT NULL,
    [LicenseNumber] [VARCHAR](50) NULL,
    [Name] [VARCHAR](50) NULL,
    [Serial] [VARCHAR](20) NULL,
    [FirstSeenUtc] [DATETIME] NULL,
    [LastSeenUtc] [DATETIME] NULL,
    [Count] [INT] NOT NULL,
    [Model] [VARCHAR](100) NULL,
    [Make] [VARCHAR](100) NULL,
    [TimestampUtc] [DATETIME] NOT NULL,
    [PortNumber] [INT] NOT NULL,
    [Code] [VARCHAR](50) NULL,
    [Peak] [FLOAT] NULL,

    CONSTRAINT [PK_Reads] 
        PRIMARY KEY CLUSTERED ([ReadId] ASC)
                WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

В этой таблице содержится более 80 миллионов строк, и простой запрос как

select count(1) from dbo.Reads

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

DTU Usage

Data IO

Я обновил базу данных до S2: 50 DTU, и выполнение вышеуказанного запроса заняло 18 минут.

Я обновил статистику, но мало помог.Я запустил хранимую процедуру Brent Ozar BlitzFirst, когда выполнялся вышеуказанный запрос, и он сказал, что база данных максимизирует ввод-вывод данных.Та же база данных, восстановленная на моем ноутбуке, возвращает количество строк в секунду.На вкладке «Производительность базы данных» рекомендаций нет.

S2: 50 DTU стоит 75 долларов в месяц, а следующий вариант - S3: 100 DTU при 150 долларов в месяц.

Я планировал создать базу данных длякаждый клиент, которого я регистрирую, но по цене 150 долларов за базу данных в месяц, довольно быстро обанкротится!

Ожидаемый уровень производительности SQL Azure?Разве такой базовый запрос не должен давать мгновенный результат?Будет ли лучше перейти на SQL Server на ВМ?

[Обновление 2019-03-10 11:35 AM EST]

Таблица имеет следующие IX

CREATE NONCLUSTERED INDEX [IX_Read_License_Code_TimeStamp] ON [dbo].[Reads]
(
    [LicenseNumber] ASC,
    [Code] ASC,
    [TimestampUtc] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

IТеперь мы видим, что некоторые столбцы можно безопасно изменить на NOT NULL, что может помочь улучшить ситуацию.

[Обновление: 2019-03-10 20:40 EST]

Я изменил таблицу насделать LicenseNumber и код NOT NULL, что заняло более 6 часов.После этого запрос подсчета выполнялся за 1 минуту и ​​32 секунды.

Следующий запрос вернул результаты за 40 секунд

select Code, LicenseNumber, TimeStampUtc from dbo.Reads Where TimestampUtc >= '2019-03-10'

1 Ответ

0 голосов
/ 13 марта 2019

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

Спасибо всем, кто прокомментировал этот вопрос. Я узнал новое.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...