Очень низкая производительность для внутреннего объединения с ограничительным предложением where (очень маленькое подмножество строк)

Question

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

Я пытаюсь объединить все три таблицы на t1.date = t2.date и t1.id_a = int.id_a и int.id_b = t2.id_b

У меня также есть предложение where, которое ограничивает данные очень конкретным диапазоном столбца даты (результирующий набор равен ~ 25k строк ).

Запуск объединенияtable 1 и таблица int (с предложением where) или объединение таблицы 2 с таблицей int (с предложением where) занимает буквально 2 секунды каждая.Затем должно быть тривиально объединить эти два набора результатов, которые составляют около 37 тыс. Строк для таблицы 1 и 200 тыс. Строк для таблицы 2.

Вместо этого для этого запроса последовательно требуется 8 минут:

select t1.date, t1.id_b, t1.other_cols, t2.other_cols
from t1 
inner join t_int on t1.id_a = t_int.id_a
inner join t_2 on t2.date = t1.date and t2.id_b = t_int.id_b
where t1.date between '2018-10-21' and '2018-12-10'

В предполагаемом (и фактическом) плане выполнения SQL Server заявляет, что он будет выполнять:

1. поиск кластеризованного индекса в t1, поиск моего диапазона дат (стоимость 33%)
2. вычислить скалярное t.id_a (стоимость 0%)
3. поиск кластеризованного индекса по t2, поиск моего диапазона дат (стоимость 33%)
4. вложенного цикла для объединения [2] и [3] (стоимость 0%)
5. поиск не кластеризованного индекса по t_int, поиск t_int.id_a = t1.id_a и t_int.id_b = t2.id_b (стоимость 33%)
6. вложенный цикл для присоединения [4] и [5] (стоимость 0%)
7. вычисление скалярного t.date, t_int.id_b (стоимость 0%)

Table 1:
date,
id_a,
other columns

(3,2 м строк,date и id_a - первичный ключ с кластерным индексом)

Table 2:
date,
id_b,
other columns

(18,5 млн строк, date и id_b - первичный ключ с кластерным индексом)

Таблица сопоставления:

id_a,
id_b,
other columns

(35 тыс. Строк, id_b is первичный ключ с кластеризованным индексом, дополнительный non_clustered индекс для [id_a, id_b, other_col])

Нет никаких других индексов и никаких ограничений вообще (кроме упомянутых ограничений первичного ключа).

Iуже перестроил индекс на t2

Может кто-нибудь помочь с тем, что мне нужно сделать?

Answer 1

Я уже перестроил индекс на t2, потому что он был фрагментирован.Но я не перестраивал индекс по t1 или t_int, так как они выглядели нормально.

Благодаря предложению Мохаммада Мохаббати в комментариях я перестроил их все, и теперь запрос выполняется менее чем за 1 секунду.

Так что ответ здесь, который может быть полезен для других с похожими проблемами, это «перестроить все индексы, даже если они выглядят хорошо»