Запрос

← →
Polevi © (2004-01-30 10:31) [0]

Есть таблица Transacts

ID INT IDENTITY PRIMARY KEY CLUSTERED
OperDate - DATETIME
Aricle - INT
Company - INT
Source - INT
Project - INT

все поля проиндекированы
Debet MONEY, KREDIT MONEY

в таблице около 100 тыс записей

запрос вида

SELECT Project, SUM(Debet), SUM(Kredit)
FROM Transacts T
JOIN GetArticles(@Articles) A ON T.Article=A.ID
JOIN GetCompanies(@Companies) C ON T.Company=C.ID
JOIN GetSources(@Sources) S ON T.Source=S.ID
JOIN GetProjects(@Projects) P ON T.Project=P.ID
WHERE OperDate BETWEEN @DateFrom AND @DateTo
GROUP BY Project

(GetXXX - ф-ия, разворачивающая строку идентификаторов в таблицу с полем ID)

выполняется порядка 4 секунд, execution plan говорит что все время пожирает clustered index scan

мне кажется что для 100 тыс записей могло бы работать и побыстрее
блокироки исключены - работаю монопольно

может быть у кого есть соображения как ускорить сие ?

← →
Fiend © (2004-01-30 11:14) [1]

А функции которые вы используете в запросе возвращают по одной строке? (это так для информации)

Хотя конечно дюже медленно. У меня на 13 млн с пятью полями и одним лишь кластерным индексом выбирало мгновенно

← →
Polevi © (2004-01-30 11:21) [2]

>Fiend © (30.01.04 11:14) [1]
ф-ия возвращает таблицу с колвом записей >= колву идентификаторов переданных в качестве параметра (они там через запятую) - разворачивает дерево

← →
Fiend © (2004-01-30 11:42) [3]

А что если провести эксперимент в поисках провала производительности?

вставить результат функций в четыре отдельные таблицы
а в процедуру (ради эксперимента) подставить таблицы вместо функций? Это недолго осуществить

← →
stone © (2004-01-30 11:56) [4]

> Polevi © (30.01.04 11:21)

Существует ли индекс для OperDate ?
Как быстро отрабатывает функция GetXXX?

← →
Delirium © (2004-01-30 12:02) [5]

Результат GetXXX - во временную таблицу, на временную таблицу - кластерный индех, и только потом - в join.

← →
Polevi © (2004-01-30 12:05) [6]

>Fiend © (30.01.04 11:42) [3]
это ничего не меняет

>stone © (30.01.04 11:56) [4]
индекс есть

GetXXX работает очень быстро - она сканирует справочник, размер справочника не превышает 300 записей - то есть ф-ия может возвратить максимум 300 записей если ей в качестве парметра передать root дерева

убрал кластер с Id - стало работать процентов на 20 побыстрее - теперь вместо clustered index scan все жрет bookmark lookup

← →
Polevi © (2004-01-30 12:07) [7]

>Delirium © (30.01.04 12:02) [5]
CREATE FUNCTION GetArticles(@Articles VARCHAR(4096))
RETURNS @TT TABLE (ID INT PRIMARY KEY CLUSTERED) AS
BEGIN
..
..

Предлагаю завести top 10000 и поочерёдно комментировать join-ы, и таким образом найти тормозящий

> Polevi © (30.01.04 12:05)

немного ускорит работу если индекс на OperDate сделать кластерным, но тем не менее проблема кажется в JOINах

всем спасибо господа, разобрался
ошибка моя :)
выборка делалсь из вьюхи где от DATETIME вызовом ф-ии отсекалось время - соотв. индекс на дате не работал - отсюда скан
убрал вызов ф-ии - все взлетело, чего и следовало ожидать

Запрос Найти похожие ветки