Простой запрос на выбор выполняется вечно

Question

Простой SQL Select - это запрос, выполняемый навсегда для определенного идентификатора в SQL Server 2012.

Этот запрос выполняется вечно; должно вернуть 10000 строк:

select * 
from employees 
where company_id = 34

Если я изменю запрос на

select * 
from employees 
where company_id = 12

очень быстро возвращает 7000 строк.

Employees - представление, созданное путем объединения разных таблиц.

Может ли быть проблема в представлении?

Answer 1

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

Я предполагаю, что строки для компании 12 встречаются перед строками для компании 34.

Если это так, то индекс (company_id) должен помочь.

Могут быть и другие причины. Вот две другие возможности:

• Конфликт для строк с company_id 34, которые вызывают задержки при чтении данных (это будет зависеть от уровня изоляции, который вы используете, и характера одновременных обновлений).
• Столбец неограниченного размера, заполненный очень большими значениями для company_id 34 и пустым или очень маленьким для 12.

Могут быть и другие возможности.

Answer 2

Не глядя на структуру таблицы и план выполнения, вот несколько вещей, которые можно предложить помимо того, что Гордон уже рассмотрел:

1. Не могли бы вы создать индексы для базовых таблиц, которые могут охватывать этот запрос? Это будет включать в себя индекс по столбцам «поиск» и «сортировка» (объединения, предложение where, упорядочение по, группировка по, отличные) и включение столбцов SELECTED в часть INCLUDE индексов (в случае некластеризованного индекса хранилища строк)? Цель состоит в том, чтобы увидеть «поиск по индексу» в плане выполнения.
2. Обновить статистику по базовым таблицам. (И, как примечание, предложил бы включить статистику «AUTO CREATE» и «AUTO UPDATE», если у вас нет причин не делать этого автоматически в вашем приложении)
3. Также хотелось бы знать, когда в последний раз выполнялась дефрагментация на сервере. Длительная дефрагментация может быть очень хорошей причиной того, почему вы можете увидеть подобные проблемы с определенными значениями, особенно с таблицей, в которой происходит много операций записи.
4. Выполнить запрос еще раз. Даже если у вас нет правильной информации о # 3 выше, вы можете попытаться выполнить шаг пропуска запроса № 3.
5. Во время выполнения запроса проверяет статистику ожидания на сервере запросы в dmvs: sys.dm_os_wait_stats и sys.dm_tran_locks. пожалуйста проверить, является ли ожидание из-за CXPACKET (ожидание из-за других параллельных процессы) или PAGEIOLATCH (чтение с диска, а не ОЗУ) или блокировки. Это является отправной точкой расследования, которое даст вам первопричину, и вы можете принять соответствующие меры.
6. Дополнительная быстрая проверка может быть: проверка «Доступной оперативной памяти» в диспетчер задач сервера. Убедитесь, что оперативная память SQL Server не используется некоторые другие ненужные приложения / сеансы.

Answer 3

Одна из вещей, которую вы можете сделать, чтобы ускорить процесс, - это индексировать столбец company_id, так как индекс b-дерева ускорит поиск.