Дилемма производительности T-SQL при циклическом просмотре большой таблицы (подробности внутри)

Question

Допустим, у меня есть таблица Big и Bigger.Мне нужно циклически перебирать таблицу Big, которая проиндексирована, но не последовательная (поскольку это фильтр последовательно индексированной таблицы Bigger).

В этом примере, скажем, мне нужно было перебратьоколо 20000 строк.

Должен ли я сделать 20000 из них

set @currentID = (select min(ID) from myData where ID > @currentID)

или

Создание (большой) временной таблицы с последовательным индексированием (копия таблицы Big)и сделать 20000 из

@Row = @Row + 1

?

Я представляю, что выполнение 20000 фильтров из таблицы Bigger просто для получения следующего идентификатора является тяжелым, но поэтому должно заполнять большой (*Временная таблица размером 1021 *) для добавления фиктивного столбца идентификаторов.

Это решение где-то еще?Например, если бы я мог циклически просмотреть результаты оператора select (фильтр таблицы Bigger, которая порождает "table" (фактически набор результатов) Big) без необходимости создания временных таблиц, это было бы идеально, ноКажется, я не могу добавить что-то вроде фиктивного столбца IDENTITY (1,1) к результатам.

Спасибо!

Answer 1

Вам нужно предоставить больше информации о том, каков будет ваш конечный результат. Строковая обработка требуется очень редко (и почти всегда это наихудший вариант с точки зрения производительности).Из этой статьи вы узнаете, как выполнять множество задач на основе набора: http://wiki.lessthandot.com/index.php/Cursors_and_How_to_Avoid_Them

Если вы просто хотите получить временную таблицу с удостоверением, вот два метода:

create table #temp ( test varchar (10) , id int identity)
insert #temp (test)
select  test from mytable

select  test, identity(int) as id into #temp from mytable

Answer 2

Я думаю, что объединение послужит вашим целям лучше.

SELECT BIG.*, BIGGER.*, -- Add additional calcs here involving BIG and BIGGER.
FROM TableBig BIG (NOLOCK)
JOIN TableBigger BIGGER (NOLOCK)
  ON BIG.ID = BIGGER.ID

Это ограничит набор, с которым вы работаете. Но опять же, все сводится к специфике вашего решения.

Помните, что вы также можете выполнять массовые вставки и массовые обновления.

Answer 3

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