Вкратце, идея состоит в уменьшении количества Nested Loops при обработке больших объемов. Для этого создаем промежуточную таблицу, в которой уже есть упорядоченные пары значений:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT
a1.val AS c1, a2.val AS c2
INTO
a2
FROM
zones AS a1 CROSS JOIN zones AS a2
WHERE
a1.val < a2.val
CREATE CLUSTERED INDEX idx1 ON a2(c1, c2)
CREATE INDEX idx2 ON a2(c2)
Для простоты используем только 2 таблицы в декартовом произведении, но можем использовать и больше. Затем при помощи данной таблицы пар получаем запрос вида:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SELECT
t1.c1 AS c1, t1.c2 AS c2,
t2.c1 AS c3, t2.c2 AS c4,
t3.c1 AS c5, t3.c2 AS c6,
t4.c1 AS c7, t4.c2 AS c8,
t5.c1 AS c9, t5.c2 AS c10
FROM
a2 AS t1
INNER JOIN
a2 AS t2 ON t2.c1 > t1.c2
INNER JOIN
a2 AS t3 ON t3.c1 > t2.c2
INNER JOIN
a2 AS t4 ON t4.c1 > t3.c2
INNER JOIN
a2 AS t5 ON t5.c1 > t4.c2
результаты которого можно сохранять в нужном формате.
Не совсем ясна необходимость хранения столь большого массива комбинаций в материализованном виде, также смущают сложности, которые обязательно возникнут при добавлении новых зон, ибо добавление всего одной зоны к уже имеющимся 60 увеличит объем хранимой информации на 20%. Т.е. 4 ТБ становятся 4.8 ТБ, 62 зоны - 5.7 ТБ, и так далее. Опять же, объем индексов тоже будет расти, как и сложность в обслуживании данной таблицы. Естественно, часть проблем можно решить используя COLUMNSTORE, но, ИМХО, имеет смысл рассмотреть варианты с представлениями или процедурами/функциями для реализации данного функционала.
