2014-09-02 2 views
3

У меня есть одна огромная хранимая процедура, которая собирает данные из таблиц в 3 таблицы тем (табличные переменные).Сохраненная процедура, выполняющая оператор select неопределенно

@table1: 50,000 records 
@table2: 23,000 records 
@table3: 15,000 records 

После получения данных, хранимая процедура выполняется один большой оператор выбора (180 строк), который преобразует данные из этих таблиц временных и некоторых физических таблиц в формате XML и возвращается клиенту.

Я не могу опубликовать хранимую процедуру здесь из-за конфиденциальности проекта. Хранимая процедура застревает в этом заявлении select. Даже после запуска хранимой процедуры в течение 24 часов она не завершила выполнение.

Затем я заменил все переменные таблицы локальной временной таблицей (#table1, #table2, #table3). К моему удивлению, хранимая процедура успешно выполнена с теми же данными.

Я не могу понять разницу b/w два подхода; и почему хранимая процедура выполнялась неограниченно с table variables?

+0

Кто скажет, что переменные таблицы находятся в памяти? http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/30/sql-server-table-variable-vs-local-temporary-table.aspx - переменные таблицы могут жить на диске, в tempdb - быть точным. – TomTom

+0

@TomTom Спасибо, что исправил меня, отредактировал мое сообщение – Jaguar

ответ

2

Табличные переменные являются немного сложнее, потому что

  1. они не имеют статистические данные, связанные с ними
  2. оптимизатор запросов SQL Server - из-за отсутствия статистических данных по этим переменным таблицы - всегда предполагает, что они содержат только 1 номер.

Эти «недостатки» могут привести к тому, что оптимизатор запросов будет запущен - в очень плохих отношениях, похоже! Предполагая, что одна строка может привести к очень неэффективным планам выполнения, если у вас действительно есть значительно больше строк в этих табличных переменных.

Если вы используете 5 или 10 строк - не biggie - но в вашем случае вы используете десятки тысяч строк, что составляет значительно отличается от одной строки.

В таком случае я бы всегда рекомендовал использовать «правильные» временные таблицы вместо переменных таблицы.

+0

Фактически неправильно, поскольку вы можете иметь индекс - через приамрический ключ - по переменной таблицы. http://blogs.msdn.com/b/blogdoezequiel/archive/2012/12/01/table-variables-and-row-estimations.aspx#.VAV_QPmSyZA также объясняет проблему с предполагаемой 1-й строкой и тем, как работать Это. Не все это мрачно ... – TomTom

+0

@TomTom: OK - вы * можете * индексировать переменные таблицы. Но согласно [этому блогу Kendra Little blog] (http://www.brentozar.com/archive/2014/04/table-variables-good-temp-tables-sql-2014/), даже в SQL Server 2014, таблица переменные ** не имеют статистической поддержки ** - поэтому оценки строк будут ** ВЫКЛ ** большое время ..... –

Смежные вопросы