Выполнение одного и того же простого оператора select или хранимой процедуры в SQL Azure занимает много времени или времени ожидания

Эти простые запросы выполняют большое сканирование таблицы и включают чтение всех строк. Если таблица имеет кластерный индекс, вам не нужно выполнять SELECT COUNT (*), чтобы узнать количество записей в таблице. Следующий запрос должен выполнить это быстрее:

SELECT OBJECT_NAME(ps.object_id) , i.name , row_count 
FROM sys.dm_db_partition_stats AS ps INNER JOIN sys.indexes AS i 
ON ps.index_id = i.index_id AND ps.object_id = i.object_id 
WHERE i.name like '%logitem%'

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

Вы также можете попробовать добавить в запрос бесполезное предложение WHERE, как показано ниже, и вы можете повысить производительность.

SELECT count(*) 
FROM logitem 
WHERE id > 0

Где Id - это столбец с автоидентификацией.

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

1. Поскольку вы используете только счетчик, индексы не играют никакой роли. Хотя я понимаю, что в другом ответе говорится об использовании where id>0, но лазурный должен подсчитывать 1M строк без 30-секундного тайм-аута. Но для других запросов вам понадобятся индексы, иначе Azure не сработает.

2. Убедитесь, что ваш сервер не находится на техническом обслуживании, это малая вероятность, но это случается с нами, мы на s4, и иногда наш сервер просто замедляется, но через 10-30 минут он работает нормально. Может быть, на самом оборудовании задействован какой-то процесс, который его замедляет.

3. Это наиболее важная причина медленного выполнения, особенно если на вашем сервере происходит много операций записи и удаления. Проверьте размер базы данных. База данных Azure фрагментировалась слишком быстро, мы должны оптимизировать ее фрагментацию данных каждые 10 дней. Если ваш размер bacpac составляет 100 МБ, а размер вашей базы данных в Azure составляет 5-6 ГБ, то это определенно нуждается в оптимизации, так как было сгенерировано много фрагментов. MSDN дал несколько запросов для воссоздания индексов и удаления фрагментации, я не помню их URL, но простой поиск в Google даст это. Это должно ускорить процесс.

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

Вам следует сделать шаг назад и обдумать свое предположение: 1. «производительность должна быть примерно одинаковой» - у вас больше данных в одном случае, чем в другом. В пределе следует ожидать, что производительность второго потенциально будет несколько ниже исходной.

Теперь давайте разберемся, «почему» это может быть медленнее, и как вы можете расследовать каждый случай: Шаг 1. Просмотрите планы запросов для каждого случая и посмотрите, что у вас есть. Скорее всего, у вас будет что-то вроде: StreamAgg <- Сканирование кластерного индекса (если у вас есть другие индексы b-дерева, вы можете сканировать один из них, и это может быть быстрее, поскольку индекс не будет таким широким и, следовательно, в индексе будет меньше страниц для сканирования)

Шаг 2. Вы можете посмотреть фактическое время выполнения и использование ресурсов для каждого запроса, чтобы понять, почему они разные. Один из способов сделать это - запустить «установить время статистики», затем «включить статистику io», а затем выполнить запрос. он будет выгружать дополнительную информацию в SSMS, когда вы запустите запрос оттуда. (Об этом можно прочитать здесь: https://docs.microsoft.com/en-us/sql/t-sql/statements/set-statistics-io-transact-sql?view=sql-server-2017.)

Если вы просмотрите результаты каждого из них, вы можете найти причины, по которым производительность различается. Одно из возможных объяснений состоит в том, что объем памяти ограничен в S2, и вы находитесь как раз на границе, где все страницы помещаются в памяти, а не в двух примерах. В этом случае выполнение запроса count (*) потребует циклического перебора всех страниц и выполнения гораздо большего количества операций ввода-вывода, чем в меньшем случае, когда все они могут быть уже в памяти.

Шаг 3. Вы также можете потенциально изучить хранилище запросов, чтобы понять, почему одно обращение выполняется быстро, а другое - нет. Обзор того, как его использовать, находится здесь: https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-2017 Примечание: он включен по умолчанию в SQL Azure, поэтому вы можете просто посмотреть временное окно при выполнении запросов, чтобы получить представление о том, что происходило в то время в вашей базе данных.

Наконец, вы можете подумать о том, как ускорить выполнение запроса, если вам нужно, чтобы он выполнялся быстрее. * создание узкого индекса b-дерева в таблице может помочь для этого одного запроса (count (*) не возвращает никаких столбцов, а просто требуется количество строк из некоторого нефильтрованного индекса). * вы можете использовать Columnstore (для которого требуется S3 или выше по соображениям памяти). Этот тип индекса, ориентированного на столбцы, оптимизирован для такого типа запросов и будет намного быстрее по мере увеличения размера таблицы в будущем.

Надеюсь, что поможет