Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.01.31;
Скачать: [xml.tar.bz2];

Вниз

Вопрос по SQL и Interbase.   Найти похожие ветки 

 
VL   (2001-12-27 10:49) [0]

Знатоки, может кто знает как решить проблему.
Посылается на сервер запрос
select * from <TABLE>
left join .....
left join .....
left join .....
where <......>
сей запрос считается 7 секунд.
Если вместо * указать sum(...), то он считается 30 сек.
Я, может по незнанию считал, что сумма должна считаться быстрее чем общая выборка.
Если возможность ускорить получение ответа по просчету.


 
Alexandr   (2001-12-27 11:13) [1]

может есть, но скорее всего нет.
select * ведь просто делает выборку и все (правда, выдает часть выборки на клиента), а select sum должен выбрать все данные, да потом еще и просуммировать


 
Romkin   (2001-12-27 11:25) [2]

оформи в виде select SP, в for select убери left join (медленно работает), просто в теле цикла делай селекты как надо, а потом просто
select sum(...) from sp_name(...)
или сразу в процедуре суммируй (Тогда left join точно не нужны)


 
VL   (2001-12-27 11:36) [3]

Что значит select SP?
Если у меня в left join идет проверка, а надо-ли эти данные сумировать.
Я попытался сделать это в процедуре, используя цикл for, но он тоже считает долго.



 
Romkin   (2001-12-27 11:59) [4]

Это и есть select SP - которая выдает набор данных.
Приведи весь запрос, может, что-то не так - обычно при суммировании join не нужен...


 
VL   (2001-12-27 12:31) [5]

select otinlnwarecode,sum(resultvalue*otinlncount*(1-otindiscount/100)*1.2),sum(otinlncount)
from outinvoicereestr
left join firmingroupe(otinfirmcode,:p0) on 1=1");
left join outinvoicelines on otinlndocmcode=otincode");
left join vlwareinclass(otinlnwarecode,:p1) on 1=1");
left join convertmoney(otinlnprice,otincrnccode,1,otindate) on 1=1
where otindate>="01.12.2001" and otindate<="31.12.2001" and rvlwareinclass=1 and rfirmingroupe=1
group by otinlnwarecode

первый left - проверка фирмы на принадлежность к группе (возврат 1 или 0)
второй - выборка шапок накладных (возврат - дата, валюта, контрагент, ...)
третий - проверка товара на принадлежность к категории (возврат 1 или 0)
четвертый - конвертация суммы (возврат - число)

проверка на принадлежность к диапазону дат, принадлежность товара к категории, принадлежность фирмы к группе.


 
Romkin   (2001-12-27 12:35) [6]

Откуда ); ??
left join пишутся в скобках:
((a left join b on...) left join c on...) left join d on...
щас посмотрю запрос


 
Romkin   (2001-12-27 12:37) [7]

Кошмар!! никогда не используй SP для join.
Какие поля кому принадлежат?? алиасы бы подписал...


 
Romkin   (2001-12-27 12:56) [8]

Примерно так... точно не скажу, но идея понятна

create procedure Gruop_sum (p0 integer, p1 integer)
returns (otinlnwarecode integer, Summa numeric(15,2), Summa2 ...)
as
declare variable invoice_UID integer;
declare variable FirmID integer;
begin
for select UID, otinfirmcode, otinlnwarecode from outinvoicereestr /* для всех реестров с условием... */
where ...
into :invoice_UID, :FirmID, :otinlnwarecode
do begin
Summa = 0;
Summa2 = 0;
if (/* проверка фирмы */) then
for select ... /* по накладным реестра */
where ...
into ...
do begin
/* вызов конвертации - если не select*/
execute procedure convertmoney(:otinlnprice,:otincrnccode,1,:otindate)
returning_values :...
summa = summa + resultvalue*otinlncount*(1-otindiscount/100)*1.2);
summa2 = summa2 + otinlncount;
...
end;
if (summa <> 0 or summa2 <> 0) then
suspend;
end
end


 
VL   (2001-12-27 13:13) [9]

т.е. ты хочешь сказать, что join тормозит вычисления и выборки.

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

И еще один вопрос: join-ы есть в обоих вариантах
select * from .... left join .... left join ....
и
select sum(..) from .... left join .... left join ....
но первый считается 7 сек а второй 30 сек - эта разница исходит от того, что в первом случае мне выдается часть данных, а во втором - он должен для себя получить полный обьем?


 
Romkin   (2001-12-27 13:21) [10]

Скорее всего условия, плюс суммирование довольно медленная операция, может IB пытается перестроить запрос по-другому.. мало ли что
по виду это отчет, поэтому рекомендую делать SP с последовательной выборкой, а также проверить планы запросов (всех), надо избегать NATURAL по большим таблицам (а для join часто так..) а также использование одновременно двух и более индексов...
Мне помню, приходилось в процедуре переворачивать запросы вверх ногами, чтобы natural шел по малой таблице
Подобные запросы - характерное время до 10 сек на PIII, с SP по таблице ~500000 записей


 
Alexandr   (2001-12-27 13:36) [11]

обратите внимание же что у него так или иначе sum
а как вы себе представляете sum и использование при этом индекса для саммирования.
Суммирование в любом случае будет использовать natural.
Хотя при этом в объединении таблиц, условиях natural не должно быть.

Здесь тормоза в этих 7 и 30 секунд идут как раз от sum и никуда от них не денешься!



 
Alexandr   (2001-12-27 13:38) [12]

выход один- смотреть чего серваку не хратает и ставить быстрее диск, мощнее процессор, больше памяти и пр.
Если уж так критично...


 
Romkin   (2001-12-27 13:39) [13]

Естественно, но если делать в процедуре - там оператора sum можно избежать (хотя и необязательно, просто я так привык), а план контролировать для условий выбора


 
Alexandr   (2001-12-27 13:48) [14]

какая разница избежать или не избежать
подумай: принцип-то тот же - проходим по всем записям и суммируем
пусть в процедуре будет sum=sum+inc_sum;
это же тоже самое по вычислительным ресурсам.
Чудес не бывает...


 
Romkin   (2001-12-27 13:58) [15]

Полностью согласен, но sp работает все же быстрее (с условием), тк процедура компилится, и план уже есть. А явное суммирование - просто удобно, можно проверять дополнительные условия перед суммированием, избегать выдачи нулевых сумм и проч. Возможно, еще и тормоза из-за большого выражения под суммой, да еще из разных таблиц


 
Alexandr   (2001-12-27 14:01) [16]

не спорю.
лучше использовать процедуру.
Но не обижаться если это выйгрыша в быстродействии не даст.


 
VL   (2001-12-27 14:06) [17]

Дело в том, что я делал сумирование в процедуре - это тоже самое время, что и sum в запросе. Исходя из экспериментов, он действительно при select * from ... передает на клиента часть вырорки. Я делал в процедуре for select * from .... do sum=sum+<данные> - время просчета тоже, что и сумирование в запросе.
Обьясните бестолковому, что такое NATURAL.
Вопрос по Interbase 5.6: есть в настройках параметров сервера два параметра Database cashe, client map size. На что они влияют?


 
GreySerg   (2001-12-27 14:11) [18]

Natural означает, что выполняется перебор всех записей, без использования индексов


 
Alexandr   (2001-12-27 14:20) [19]

database cache- это кэш страниц базы данных в памяти.
Больше 1000 тысяч ставить не надо- это плохо.
Если это число умножить на размер страницы - то будет объем ОЗУ
при этом размер страницы может быть 1024,2048, 4096,8192 байта.
Еще рекомендуют размер страницы выбирать такой-же как размер кластера на винте.
А лучше всего пробовать...
почитай еще на ib.demo.ru есть статьи по поводу повышения быстродействия.
а так могу посоветовать поставить где-то 2000 страниц в database cache. Это обычно оптимально.
Кстати, а размер базы данных, размер страницы в базе у тебя какой?


 
VL   (2001-12-27 14:28) [20]

база - 550 М
Database cashe = 8192
client map size = 8192


 
Alexandr   (2001-12-27 14:29) [21]

ок.
неплохо...
а ОЗУ сколько на серваке?


 
VL   (2001-12-27 14:35) [22]

256М 6нс dim"ы
raid масив высшей (0 или 5 непомню) категории 3 scsi винта 10700 об по 9Гб = 18 Гб пространства.
тачка двухпроцессорная 2 х 550M Xeon


 
Alexandr   (2001-12-27 14:44) [23]

нескромный вопрос: ты IB привязал к одному процессору?
нужна спец. утилита ibaffinity с ib.demo.ru
а ОС какая?
а вообще-то 256 метров маловато.


 
VL   (2001-12-27 15:00) [24]

NT4
память по счетчику памяти не подымается выше половины.


 
Alexandr   (2001-12-27 15:04) [25]

а ты не по счетчику смотри. Ты посмотри сколько у тебя под файловый кэш используется- это в счетчик не попадает.
Надо другие утилитки пробовать.
как насчет привязки? Без нее плохо очень.


 
VL   (2001-12-27 17:28) [26]

отменить (снять) потом привязку можно?


 
Alexandr   (2001-12-28 07:15) [27]

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.01.31;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.51 MB
Время: 0.006 c
1-99995
Анатолий
2002-01-15 06:03
2002.01.31
MediaPlayer несколько раз


14-100039
GydruS
2001-12-05 08:33
2002.01.31
Как отучить людей от лапанья экранов?(в компьютерных классах)


4-100095
Miwa
2001-11-30 20:07
2002.01.31
SendMessage


1-99956
MystiX
2002-01-13 18:02
2002.01.31
Heeelp!!!


3-99841
EternalWonderer
2001-12-25 15:47
2002.01.31
Размер поля NUMBER в ORACLE





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский