SQL-запросы чрезвычайно медленные при обращении к первичному ключу

Question

У меня есть таблица MS SQL с около 8 миллионами записей.В столбце «ID» имеется первичный ключ (с кластеризованным индексом с фрагментацией всего 0,8%).Когда я запускаю, казалось бы, любой запрос, ссылающийся на столбец ID, этот запрос занимает очень много времени (и фактически в конечном итоге приводит к сбою моего приложения).Это включает в себя простые запросы, такие как «SELECT * FROM table WHERE ID = 2020».В отличие от запросов, которые не ссылаются на идентификатор (например, «SELECT TOP 100 * из таблицы») просто отлично.

Есть идеи?

Answer 1

Я бы проверил статистику, если вы уже проверили фрагментацию

Они были отключены или не обновлены?

Их быстрый способ проверить это использовать STATS_DATE

Answer 2

Если запрос занимает 10 минут (!?!) вы что-то серьезно ошиблись. Даже сканирование таблицы из 8 миллионов записей должно занять всего секунду или две. Я бы проверил журнал событий на наличие признаков неизбежного аппаратного сбоя или попытался бы переместить базу данных на другой сервер, чтобы узнать, есть ли какая-то другая аппаратная ошибка.

Answer 3

Я подозреваю, что запрос выполняет сканирование таблицы (или, по крайней мере, сканирование индекса по действительно большому или статистически устаревшему индексу).Создайте примерный план выполнения (Control-L в SSMS) или попросите SQL Server вернуть план выполнения, который он фактически использовал, потому что он иногда отличается (Control-M, чтобы включить его, а затем выполнить ваш запрос в обычном режиме - он создаст новую вкладку рядом с вашимрезультаты).

После того, как у вас есть план выполнения, выполните поиск таблицы или индекса, и это, скорее всего, источник вашей медлительности.«Предполагаемый план выполнения» может даже рекомендовать и индексировать, чтобы помочь запросу быстрее возвращаться - более новые версии SQL Server / SSMS включают эту функцию.

Хотя я подозреваю, что вы не найдете ничего интересного - ваш запростолько один шаг - вот краткое введение в чтение планов выполнения: http://sqlserverpedia.com/wiki/Examining_Query_Execution_Plans

Answer 4

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

Answer 5

Является ли ID GUID случайно?SQL Server имеет проблему с созданием хэша для столбцов GUID, из-за чего они плохо работают в индексах.

Примите точный запрос и возьмите «примерный план выполнения» из Sql Server Management Studio.Если ваш запрос запускает сканирование таблицы (чего не должно быть), то это объясняет время.Возможно, план может показать вам, что еще происходит.

Я предполагаю, что вы уже перестроили индекс (на основе вашего комментария фрагментации на 0,8%).