Ответ 1
Я собираюсь выйти на конечность и предположить, что у вас много строк, где ID = 1.
Если нет, пожалуйста, поправьте меня.
Одна из возможных причин, по которой SQL Server обрабатывает ваш запрос медленным, заключается в том, что он смотрит на запрос и идет:
Хмм, интересно, что он собирается передать для этого параметра.
это будет 1? где у меня около миллиона строк?
или, возможно, 1742, где у меня всего 3 человека Я просто не знаю, мне лучше выполнить сканирование таблицы, чтобы создать план выполнения, который будет охватывать все мои базы.
Если столбец или набор столбцов имеют низкую избирательность (то есть число уникальных значений намного меньше числа строк), SQL Server иногда возвращается к таблицам или аналогичным, просто чтобы получить все строки детерминированным образом.
По крайней мере, это был мой опыт. В частности, я видел такое же поведение при выборе диапазона дат в таблицах с привязанными по времени данными, делая WHERE dt <= @dt AND dt >= @dt для получения всех строк, где @dt находится внутри периода времени в этой строке, возвращается к сканированию таблицы, а затем, когда я помещаю фактическую дату в SQL как литерал, она выполняется намного быстрее.
Проблема здесь в селективности, SQL Server не знает, как наилучшим образом удовлетворить все сценарии при построении плана выполнения для вашего оператора, поэтому он попытается угадать.
Попробуйте добавить подсказку запроса, чтобы указать типичное значение для параметра, то есть.:
sp_executesql "select * from tablesView where Id = @Id option (optimize for (@id = 1742))", N"@Id int", @Id=1