SQL Server: как сканирование таблицы может быть таким дорогим на крошечной таблице?

Question

Я смотрю на план выполнения из проблемного запроса.

Я вижу, что 45% плана выполняется при сканировании таблицы с семью (7) строками данных.

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

Я читал здесь и чувствую, что это может быть просто из-за несмежных данных - индексов в рассматриваемой таблице нет вообще.В целом, хотя наша база данных имеет большой размер (7 ГБ) и занята.

Мне бы очень хотелось узнать, что думают другие - спасибо!

РЕДАКТИРОВАТЬ:

Запрос выполняется очень часто и заходит в тупик (и выбран в качестве жертвы),Сейчас для запуска требуется от 300 мс до 500 мс, но это займет больше времени, когда база данных будет загружена.

Запрос:

select l.team1Score, l.team2Score, ls.team1ExternalID, ls.team2ExternalID, et.eventCategoryID, e.eventID, ls.statusCode 
from livescoretracking l(nolock) 
inner join liveScores ls (nolock) on l.liveScoreID = ls.liveScoreID 
inner join db1.dbo.events e on e.gameid = ls.gameid 
inner join db1.dbo.eventtype et (nolock) on e.eventTypeID = et.eventTypeID 
inner join eventCategoryPayTypeMappings ecb (nolock) on ( et.eventCategoryID = ecb.eventCategoryID and e.payTypeID = ecb.payTypeID and ecb.mainEvent = 1 ) 
where ls.gameID = 286711 order by l.dateinserted

Таблица проблем - это таблица eventCategoryPayTypeMappings - спасибо!

Answer 1

Взаимные блокировки обычно более характерны для проблемы упорядочения доступа к ресурсам, чем, в частности, для проблемы с дизайном запросов. Я бы посмотрел на другого участника (ов) в тупике и взглянул на то, какие объекты были заблокированы в каждой транзакции, которые были необходимы другим (и). Если вы сможете изменить порядок, чтобы обеспечить согласованный порядок доступа, вы сможете полностью избежать проблем с конфликтами.

Answer 2

Если в таблице нет индексов, обработчик запросов будет всегда выполнять сканирование таблицы.Нет другого способа обработать данные.

Многие платформы РСУБД будут выполнять сканирование таблицы на таком маленьком столе, даже если являются индексами.(Я не уверен насчет SQL Server конкретно.)

Я бы больше интересовался фактическими числами в плане запросов.

Answer 3

Процентная стоимость не имеет смысла, не зная общую стоимость в реальном выражении.например, если запрос занимает 1 мс, чтобы выполнить 45% -ную стоимость сканирования таблицы, составляет .45 мс, что не стоит пытаться оптимизировать, если выполнение запроса занимает 10 секунд, тогда 45% -ная стоимость является значительной и заслуживает оптимизации.

Answer 4

Сканирование таблицы в таблице из семи строк не дорого. Запрет подсказок запроса, механизм запросов будет использовать сканирование таблицы на такой маленькой таблице независимо от того, какие индексы существуют. Можете ли вы показать нам больше о рассматриваемом запросе и проблеме с планом выполнения?

Answer 5

Сканирование таблицы на маленькой таблице - неплохая вещь. Если она помещается в одном чтении в кэш, оптимизатор рассчитает, что сканирование таблицы обходится дешевле, чем чтение через цепочку индексов.

Iрекомендовал бы кластеризованный индекс только в том случае, если вы хотите убедиться, что содержимое будет «иметь тенденцию» сортироваться таким образом (хотя вам потребуется явный порядок, чтобы гарантировать это).

Answer 6

Это действительно зависит от того, сколько времени занимает запрос от начала до конца. 45% не означает, что это займет много времени, если запрос занимает всего 10 мс. Все, что он действительно говорит, это то, что большую часть времени тратится на сканирование таблицы, что понятно.

Наличие индекса может помочь при росте таблицы и, вероятно, является неплохой идеей, если вы не знаете, что эта таблица не будет расти. Однако вы обнаружите, что добавление индекса в таблицу с 7 записями практически не влияет на производительность.