необходима помощь в SQL Query

Question

Ниже мой SQL запросы, которые идут против 30000000 строк и его занимает 6 минут, чтобы запустить индексов defiened для всех столбцов, используемых в ИНЕКЕ как WLL, как внутреннее соединение Пожалуйста, помогите мне

SELECT auditData.id,nstmp.ProviderMaster_ID as CDRComment,Auditdata.Calltypetag 
from Auditdata AuditData 
inner join NoSeriesMaster_temp nstmp on nstmp.NosereisTemp like '91%' 
where Auditdata.id in (select id from auditdata_temp1 where tatcalltype is null) 
    and AuditData.CallTolen=12 and Auditdata.Callto like nstmp.NosereisTemp + '%' and  AuditData.AuditMaster_ID=74 

спасибо заранее

Answer 1

Ваш запрос очень интенсивный, bsesides вы итерацию большой стол, вы делаете присоединиться и вложенный запрос.

Возможно, вы можете создать представление с результатом вложенного sql. В любом случае вы должны зарезервировать запрос, не используя эту сложность.

Еще одно решение, которое можно было бы рассмотреть, чтобы разделить большую таблицу на кусочки или объединить данные, используя некоторые методы OLAP.

Какой двигатель вы используете?

Answer 2

Вы получили LIKE выражения в обеих ваших WHERE пункта (like nstmp.NosereisTemp + '%') и ваш JOIN ON пункта (например, '91% '). Это всегда будет медленнее, чем использование прямого сравнения, и я думаю, что это может также повлиять на то, могут ли используемые вами индексы эффективно использоваться.

Можно ли изменить таблицы, чтобы включить поле, которое вы могли бы использовать для присоединения/фильтрации? Например, можете ли вы предварительно вычислить like '91%' и сохранить значение в таблице?

Answer 3

Это будет, в лучшем случае, сканирование индексов, поскольку вы выполняете проверку условий LIKE (не сможете выполнить поиск индекса, что обычно является лучшим для производительности). Не так много вы можете сделать по этому поводу - просто проверьте план выполнения, следите за сканированием таблицы, на который нужно будет смотреть (отсутствует индекс)

Возможно, изменение условия «Auditdata.id IN» в состояние EXISTS может выполняться лучше (я предполагаю, что id - это PK в auditdata_temp1, и поэтому не будет нескольких с одинаковым значением, и в этом случае EXISTS не будет иметь огромных различий, если таковые имеются).

С этим объемом данных вы можете захотеть разделить ваши данные, которые вы можете делать с SQL 2005, но вам нужна Enterprise Edition, поэтому не может быть вариант. См. here для информации.

Покрывающие индексы - возможно, вы получите лучшую производительность с одним.

Действительно, нам нужно увидеть план выполнения, который может перебросить другие вещи в микс.

Answer 4

Суб-запрос

Во-первых, избавиться от суб-запроса и использовать объединение вместо, например:

SELECT 
auditData.id, nstmp.ProviderMaster_ID as CDRComment, Auditdata.Calltypetag 

FROM Auditdata AuditData 

INNER JOIN NoSeriesMaster_temp nstmp 
ON Auditdata.Callto like nstmp.NosereisTemp + '%' 
AND nstmp.NosereisTemp like '91%' 

INNER JOIN auditdata_temp1 adt 
ON Auditdata.id = adt.id 
AND adt.tatcalltype is null 

WHERE AuditData.CallTolen = 12 
AND AuditData.AuditMaster_ID = 74 

Это поможет немного.

Объединение с использованием как пункта

1. Это будет беспорядок вверх ваш план выполнения, как оптимизатор не может вычислить наилучший путь поиска в качестве времени выполнения изменяется значение.
2. Это текстовый поиск, который будет оцениваться для каждой строки AuditData ... не хорошо!

Решение

Добавить немного столбца NoSeriesMaster и обновлять его по графике необновляемых записей 1 Где NosereisTemp как '91%». Вместо этого используйте это значение бита в своем запросе.

Посмотрите на это изменить:

Auditdata.Callto like nstmp.NosereisTemp + '%' 

Используя подобную концепцию. Трудно точно сказать, как без знания ваших данных.

Answer 5

Вы должны смещаться вокруг JOIN ON/WHERE критериев мало, Соединить критерии должны быть предиката, которая связывает две таблицы:

INNER JOIN NoSeriesMaster_temp nstmp 
ON Auditdata.Callto like nstmp.NosereisTemp + '% 

Затем вам нужно переместить следующий предикат в разделе WHERE из по вашему запросу:

WHERE nstmp.NosereisTemp like '91%' 

Это может помочь SQL-серверу разработать более разумный план выполнения.

Если это не помогает, то вы должны смотреть на заранее вычисляя значение nstmp.NosereisTemp like '91%' - SQL Server должен быть в состоянии обрабатывать запросы такого рода прекрасно, однако это может оказать влияние на JOINS

Более того его невозможно сказать без плана выполнения, однако я могу с уверенностью сказать, что это НЕ ваш подзапрос! :-) (Не стесняйтесь попробовать переписать его как JOIN, однако я буду очень удивлен, если удаляем подзапрос, что исправить вашу проблему)