оптимизация

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
2hands
Сообщения: 21
Зарегистрирован: 06 дек 2005, 14:42

оптимизация

Сообщение 2hands » 02 апр 2010, 15:21

Добрый день!
При выполнении select-а

Код: Выделить всё

select count(*)  from 
sс inner join scf on sc.id=scf.sc_id  
inner join p4 on sc.id=p4.sc_id  
inner join p6 on sc.id=p6.sc_id 
   where sc_id!=-1 and sc.mode in (0,1,4)   and (cg = 513 or cg = 514 or cg = 714) and  (pe = 3  or pe = 4 ) and ((( scf.re=1 or  scf.re=2) and ( scf.fr=2 or  scf.fr=3 or  scf.fr=4 
   or scf.fr=5 )  and ((( p6.tm=1) and ( p6.km=12 or  p6.km=5 or  p6.km=2 or  p6.km=1 or  p6.km or  p6.km=3 or  p6.km=6 or  p6.km=9 or  p6.km=7 or  p6.km=8 ) )) 
   and (( scf.re=1 or  scf.re=2) and ( scf.fr=2 or  scf.fr=3 or  scf.fr=4 or  scf.fr=5 ) )) or (( scf.re=1 or  scf.re=2) and scf.BASE_FREE_M_MEA=0  and p6.tm=1 and p6.km=13)) 
   and (p4.ta=1 and p4.ar=11102) 
такой план

Код: Выделить всё

Plan
PLAN JOIN (SCF NATURAL,SC INDEX (RDB$PRIMARY51),P6 INDEX (FK_P6_SC),P4 INDEX (FK_P4_SC))
Adapted Plan
PLAN JOIN (SCF NATURAL,SC INDEX (PK_SC),P6 INDEX (FK_P6_SC),P4 INDEX (FK_P4_SC))
------ Performance info ------
Prepare time = 63ms
Execute time = 343ms
Avg fetch time = 343,00 ms
Current memory = 1 143 544
Как-то не нравится время 343мс. Можно ли как-нибудь улучшить?
(в sc, scf, p4 по 8-10 тыс записей, в р6 по-меньше.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: оптимизация

Сообщение kdv » 02 апр 2010, 16:02

в performance info была еще информация. А чем план-то не нравится, или время? у тебя там дофига or, <> и прочего. Вполне себе нормальное время. Будет больше данных - будет хуже, понятно. А ты не пиши такие запросы.

2hands
Сообщения: 21
Зарегистрирован: 06 дек 2005, 14:42

Re: оптимизация

Сообщение 2hands » 02 апр 2010, 16:17

именно время не нравится.
таких выборок в цикле порядка 20 тыс с разными значениями, списками значений и проч.
я думал, что-то в принципе неправильно организовано - вместо join-a использовать вложенные запросы, или count не использовать, или добавить FK

т.е. по_Вашему, для такого селекта время терпимое?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: оптимизация

Сообщение hvlad » 02 апр 2010, 17:31

2hands писал(а):т.е. по_Вашему, для такого селекта время терпимое?
Без знания о том, сколько записей в исходных таблицах, сколько чтений из них было произведено и сколько записей попало в результат - на этот вопрос тебе никто не даст ответ.
Вся эта инф-ция есть в performance info у IBE

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: оптимизация

Сообщение kdv » 03 апр 2010, 01:31

таких выборок в цикле порядка 20 тыс с разными значениями, списками значений и проч.
Поздравляю! Вы на пути убиения своей системы по производительности!
С тем же успехом можете переходить на Оракл, Вас там ждет то же самое.

2hands
Сообщения: 21
Зарегистрирован: 06 дек 2005, 14:42

Re: оптимизация

Сообщение 2hands » 05 апр 2010, 12:34

hvlad писал(а):
2hands писал(а):т.е. по_Вашему, для такого селекта время терпимое?
Без знания о том, сколько записей в исходных таблицах, сколько чтений из них было произведено и сколько записей попало в результат - на этот вопрос тебе никто не даст ответ.
Вся эта инф-ция есть в performance info у IBE
Добрый день!
Я подозреваю, что такое время не должно быть. Проблема скорее в организации бд. и скорее всего меня отошлют к Марксу с Энгельсом.
Но может что-то можно и так сказать - что изменить, добавить.
А в IBE информация такая (время выборки сегодня даже 2 сек)

Код: Выделить всё

Query Time
------------------------------------------------
Prepare       : 16,00 ms
Execute       : 2 109,00 ms
Avg fetch time: 2 109,00 ms
Memory
------------------------------------------------
Current: 1 460 116
Max    : 1 510 148
Buffers: 2 048
Operations
------------------------------------------------
Read   : 2 950
Writes : 0
Fetches: 90 484
Enchanced Info:
+--------------------------+-----------+-----------+---------+---------+---------+
|        Table Name           |   Index     | Non-Index | Updates | Deletes | Inserts |
|                                    |   reads      |   reads      |             |               |              |
+--------------------------+-----------+-----------+---------+---------+---------+
|            SCF               |         0      |     12074 |          0 |            0 |           0 |
|                             SC|        6535 |              0 |          0 |            0 |           0 |
|                             P4|             1 |              0 |          0 |            0 |           0 |
|                             P6|        4478 |              0 |          0 |            0 |            0 |
+--------------------------+-----------+-----------+---------+---------+---------+
Буду признателен, если что-то посоветуете.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: оптимизация

Сообщение kdv » 05 апр 2010, 14:42

Buffers: 2 048
Reads : 2 950

Это значит что количество чтений с диска больше чем размер кэша. С одной стороны, конечно, можно бы и кэш увеличить, но с другой стороны, десяток тысяч записей на 2 тысячах страниц - размер страницы какой? Да и для классика увеличивать размер кэша выше 2048 уже фактически некуда.

p.s. есть подозрение, что IBE у вас очень старый - вывод информации не совсем "современный".

2hands
Сообщения: 21
Зарегистрирован: 06 дек 2005, 14:42

Re: оптимизация

Сообщение 2hands » 06 апр 2010, 16:28

kdv писал(а):Buffers: 2 048
Reads : 2 950

Это значит что количество чтений с диска больше чем размер кэша. С одной стороны, конечно, можно бы и кэш увеличить, но с другой стороны, десяток тысяч записей на 2 тысячах страниц - размер страницы какой? Да и для классика увеличивать размер кэша выше 2048 уже фактически некуда.

p.s. есть подозрение, что IBE у вас очень старый - вывод информации не совсем "современный".
подозрения верные - я ка-то не заморачивался на версии IBE (как поставил когда-то версию за 2004 год так и пользовался).
Тем более, что не это причина этой проблемы :)
Ниже результаты в последнем IBE
Query
------------------------------------------------
....
Plan
------------------------------------------------
PLAN JOIN (SCF NATURAL,SC INDEX (RDB$PRIMARY51),P6 INDEX (FK_P6_SC),P4 INDEX (FK_P4_SC))

Adapted Plan
------------------------------------------------
PLAN JOIN (SCF NATURAL,SC INDEX (PK_SC),P6 INDEX (FK_P6_SC),P4 INDEX (FK_P4_SC))

Query Time
------------------------------------------------
Prepare : 16,00 ms
Execute : 2 109,00 ms
Avg fetch time: 2 109,00 ms

Memory
------------------------------------------------
Current: 799 248
Max : 989 304
Buffers: 2 048

Operations
------------------------------------------------
Read : 2 959
Writes : 0
Fetches: 90 490


Enchanced Info:
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts |
| | Total | reads | reads | | | |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| P4| 0 | 1 | 0 | 0 | 0 | 0 |
| P6| 0 | 4478 | 0 | 0 | 0 | 0 |
| SС| 0 | 6535 | 0 | 0 | 0 | 0 |
| SСF| 0 | 0 | 12074 | 0 | 0 | 0 |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
Посчитал среднюю длину записи в scf - 470б

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: оптимизация

Сообщение hvlad » 06 апр 2010, 16:47

Можно попробовать уменьшить кол-во чтений из SCF.
Раз P6 самая маленькая, то пусти натурал по ней, например так

Код: Выделить всё

select count(*)  
  from sс inner join scf on sc.id = scf.sc_id 
   inner join p4 on sc.id = p4.sc_id 
   inner join p6 on sc.id = p6.sc_id + 0
 where ...
Какой план у этого запроса ?

2hands
Сообщения: 21
Зарегистрирован: 06 дек 2005, 14:42

Re: оптимизация

Сообщение 2hands » 06 апр 2010, 17:13

hvlad писал(а):Можно попробовать уменьшить кол-во чтений из SCF.
Раз P6 самая маленькая, то пусти натурал по ней, например так

Код: Выделить всё

select count(*)  
  from sс inner join scf on sc.id = scf.sc_id 
   inner join p4 on sc.id = p4.sc_id 
   inner join p6 on sc.id = p6.sc_id + 0
 where ...
Какой план у этого запроса ?
так получилось еще хуже
Plan
PLAN JOIN (P6 NATURAL,SC INDEX (RDB$PRIMARY51),SCF INDEX (FK_SCF_SC),P4 INDEX (FK_P4_SC))

Adapted Plan
PLAN JOIN (P6 NATURAL,SC INDEX (PK_SC),SCF INDEX (FK_SCF_SC),P4 INDEX (FK_P4_SC))

------ Performance info ------
Prepare time = 47ms
Execute time = 12s 906ms
Avg fetch time = 12 906,00 ms
Current memory = 802 388
Max memory = 989 304
Memory buffers = 2 048
Reads from disk to cache = 3 252
Writes from cache to disk = 0
Fetches from cache = 107 398

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: оптимизация

Сообщение hvlad » 06 апр 2010, 18:04

2hands писал(а):так получилось еще хуже
Ну, значит оптимизатор не так туп, как о нём говорят некоторые :)

ЗЫ Всю статистику давай, а не огрызки... каждый раз нужно это говорить ? :(
И кнопку Total records в статистике ИБЕ нажми.

Опять же - читать запрос не возможно. Я его нормально форматировать не буду.
Может в where есть что-то индексируемое, но выковыривать это оттуда мне не интересно.

Навскидку - что такое
(cg = 513 or cg = 514 or cg = 714) ?
(pe = 3 or pe = 4 ) ?
(p4.ta=1 and p4.ar=11102) ?
Насколько они могут сократить соотв. таблицу ? Индексированы ли эти поля ?

2hands
Сообщения: 21
Зарегистрирован: 06 дек 2005, 14:42

Re: оптимизация

Сообщение 2hands » 07 апр 2010, 13:35

hvlad писал(а):
2hands писал(а):так получилось еще хуже
Ну, значит оптимизатор не так туп, как о нём говорят некоторые :)

ЗЫ Всю статистику давай, а не огрызки... каждый раз нужно это говорить ? :(
И кнопку Total records в статистике ИБЕ нажми.

Опять же - читать запрос не возможно. Я его нормально форматировать не буду.
Может в where есть что-то индексируемое, но выковыривать это оттуда мне не интересно.

Навскидку - что такое
(cg = 513 or cg = 514 or cg = 714) ?
(pe = 3 or pe = 4 ) ?
(p4.ta=1 and p4.ar=11102) ?
Насколько они могут сократить соотв. таблицу ? Индексированы ли эти поля ?
Статистика
Query
------------------------------------------------
.........
Plan
------------------------------------------------
PLAN JOIN (P6 NATURAL,SC INDEX (RDB$PRIMARY51),SCF INDEX (FK_SCF_SC),P4 INDEX (FK_P4_SC))

Adapted Plan
------------------------------------------------
PLAN JOIN (P6 NATURAL,SC INDEX (PK_SC),SCF INDEX (FK_SCF_SC),P4 INDEX (FK_P4_SC))

Query Time
------------------------------------------------
Prepare : 47,00 ms
Execute : 468,00 ms
Avg fetch time: 468,00 ms

Memory
------------------------------------------------
Current: 854 020
Max : 1 162 348
Buffers: 2 048

Operations
------------------------------------------------
Read : 3 254
Writes : 0
Fetches: 107 404


Enchanced Info:
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts |
| | Total | reads | reads | | | |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| P4| 14698 | 1 | 0 | 0 | 0 | 0 |
| SC| 12077 | 8904 | 0 | 0 | 0 | 0 |
| SCF| 12074 | 8850 | 0 | 0 | 0 | 0 |
| P6| 8904 | 0 | 8904 | 0 | 0 | 0 |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
Индекса только эти
ALTER TABLE SСF ADD CONSTRAINT PK_SCF PRIMARY KEY (ID);
ALTER TABLE SCF ADD CONSTRAINT FK_SCF_SC FOREIGN KEY (SC_ID) REFERENCES SC (ID);
ALTER TABLE P6 ADD CONSTRAINT PK_P6 PRIMARY KEY (ID);
ALTER TABLE P6 ADD CONSTRAINT FK_P6_SC FOREIGN KEY (SC_ID) REFERENCES SC (ID);
ALTER TABLE P4 ADD CONSTRAINT PK_P4 PRIMARY KEY (ID);
ALTER TABLE P4 ADD CONSTRAINT FK_P4_SC FOREIGN KEY (SC_ID) REFERENCES SC (ID);
другие индекса как-то пробовал, опять же с целью уменьшения времени, и получил отрицательные результаты.
указание одного значения для cg выбирает где-то 1/5 записей от общего числа
указание одного значения для pe выбирает где-то 1/7 записей от общего числа

Ответить