Есть ли какая-то причина, почему объединение двух представлений о четырехкратном объединении их времени выполнения

Question

У меня есть 2 представления, которые выбирают большие наборы данных из внешнего источника. Они не делают каких-либо вычислений или агрегаций, а только длинного оператора select.

Я использую

INNER JOIN 

, чтобы связать два представления на основе GUID.

Отдельные варианты выбора для каждого вида:

view1, 3:08 Время выполнения, 174 842 извлеченные записи

view2, 0:02 Время выполнения, 93 493 извлеченные записи

Когда я присоединяюсь к ним, я получаю следующее

Присоединение, 14:32 Время выполнения, 177 753 найденных записи

Пока что я пробовал

LEFT JOIN 
RIGHT JOIN 
INNER JOIN
JOIN

IЯ пытался соединить view1 с view2 против присоединения view2 к view1. Я попытался вызвать одно представление, а затем выбрать его во время соединения с другим представлением.

Кажется, ничто не влияет на него.

SQL ниже для справки

SELECT
    v1.guid, 
    CONVERT(DATE, v1.CreatedOn) AS CreatedOn,
    field1, 
    field2, 
    field3,
    field4,
    field5
FROM
    View1 v1
    INNER JOIN View2 V2 ON v1.guid = v2.guid
WHERE
    field6 = 'value'

(Обязательно, это не настоящие имена полей)

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

Любая помощь по оптимизации приветствуется

Answer 1

Попробуйте следующее:

SELECT *
INTO #view1
FROM view1

SELECT *
INTO #view2
FROM view2

SELECT
    v1.guid, 
    CONVERT(DATE, v1.CreatedOn) AS CreatedOn,
    field1, 
    field2, 
    field3,
    field4,
    field5
FROM #View1 v1
INNER JOIN #View2 V2 
    ON v1.guid = v2.guid
WHERE
    field6 = 'value'

Первые два оператора материализовали данные представления во временных таблицах. Если движок не может построить хороший план выполнения в исходном запросе, вышеописанное должно помочь.

Если приведенное выше не помогает, попробуйте определить временные таблицы, чтобы лучше определить первичные ключи. Примерно так:

CREATE TABLE #view1
(
    guid UNIQUEIDENTIFIER PRIMARY KEY
    ....
)

INSERT INTO #view1
SELECT *
FROM view1

Таким образом, таким образом данные должны быть упорядочены по GUID, и теоретически мы должны получить более быстрое соединение.

Вышеуказанное может привести к повышению производительности, но у нас здесь есть большая проблема - вы присоединяетесь к UNIQUEIDENTIFIER - я знаю, что вы можете видеть людей, использующих это в качестве первичного ключа, но вы обнаружите присоединение к intили bigint быстрее. Если вам нужен такой столбец guid, чтобы не показывать внутренние идентификаторы в вашем приложении или что-то еще, это не означает, что у вас не может быть целочисленного столбца для выполнения объединений в SQL.

Кроме того,если вы не можете сохранить данные в представлении во временных таблицах, вы можете проверить, как создаются индексированные представления, и если вы можете - сохранить только те данные, которые необходимы (заранее примените критерии фильтрации), например:

INSERT INTO #view1
SELECT *
FROM view1
WHERE field6 = 'value'

Итак, теперь в таблице меньше строк, верно?

Answer 2

Получается, что ответом было не выбирать более 100 столбцов в представлении, а затем выбрать из него 1 столбец! кто бы мог подумать