Здесь есть 2 различных таймаута. Время ожидания подключения (указывается в строке подключения и как свойство SqlConnection), а также время ожидания запроса (свойство SqlCommand.CommandTimeout). Значения по умолчанию:
- время ожидания соединения: 15 секунд.
- Время ожидания запроса: 30 секунд.
Тайм-аут запроса определяется как " совокупный тайм-аут для всех сетевых чтений во время выполнения команды или обработки результатов. Тайм-аут все еще может возникнуть после возвращения первой строки, и не включает пользовательскую обработку время, только время чтения по сети."
Множество причин, по которым время чтения сети расходуется (включая конфликты в сети). Вещи, которые я бы искал:
- блокировка в SQL Server.
- статистика устарела.
- план выполнения. У вас есть хороший план выполнения в анализаторе запросов?
- Кэш устаревшего / субоптимального плана выполнения. Если проблемный запрос является параметризованной хранимой процедурой или запросом, кешируется план выполнения, полученный при первом выполнении запроса. Он основан на значениях параметров этого первого вызова. Если предоставленные аргументы для этого вызова являются выбросами / ненормальными значениями, кэшированный план выполнения вполне может быть неоптимальным для большинства выполнений.
- хранимая процедура перекомпилируется. Хранимая процедура, которая чередует SQL / DML и DDL (например, чередует операторы SELECT с созданием временных таблиц), будет вызывать перекомпиляцию при каждом создании временной таблицы. Блокировки компиляции препятствуют выполнению других исполнителей той же хранимой процедуры до завершения перекомпиляции плана выполнения. Если вы используете временные таблицы, они должны быть объявлены заранее, до выполнения любого DML CRUD.
Если вы указали тайм-аут соединения через строку соединения, то существующие соединения SQL Server в пуле не используются: вы получаете новые соединения, поскольку кэш пула соединений основан на используемой строке соединения. Вы правильно утилизируете () свои соединения / команды / и т. Д.? Если вы оставляете открытый читатель с данными для чтения, вы, вероятно, оставляете блокировку на месте, которая вызывает проблемы. Иногда SQL Server задыхается, разрывает соединение и оставляет также призрачный спид, что вызывает аналогичные проблемы конфликта блокировок.