Долго выполняется запрос / Firebird, InterBase

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Долго выполняется запрос

49 сообщений из 49, показаны все 2 страниц

все

Долго выполняется запрос

#39679327

KillerProg

Гость

Здорова товарищи!!!

У меня выполняется долго следующий запрос

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

with tm as (
                  select od.productid,
                            sum(od.quantity) as qty , sum(od.quantity*od.unitprice) as proiz
                             from ordersdetails od inner join orders o on o.id = od.ordid
                                                  inner join products p on od.productid = p.id
                  where o.orderdate+o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'
                    --    and o.itemkch = 0
                  group by od.productid

) select
     t.productid,
     p.productname,
     t.qty as qty,
     t.proiz as sm
  from tm t left join products p on t.productid = p.id

В таблице orders 110 000 записей
В таблице orderdetails 330 000 записей

Запрос в программе я выполняю через pFibDataSet

Запрос выполняется, вместе с отображением результатов, где то 20 секунд

Как мне оптимизировать этот запрос? Где слабые места?

Спасибо...

...

Рейтинг:

0 / 0

26.07.2018, 00:13

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679354

Щукина Анна

Участник

Сообщения: 1 496

Рейтинг: 0 / 0

KillerProg,

в-нулевых, сколько записей из ордерс попадает под условие фильтрации (o.orderdate+o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00')?

во-первых, зачем дважды ходить в таблицу products? за один проход нельзя вытащить все нужные данные (productname в данном случае)? и почему второе участие таблицы (в основной части запроса) записано через LEFT JOIN? Разве в WITH-подзапросе возможен возврат записей, несуществующих в products ? Там же у вас она связывается через INNER JOIN с остальными таблицами...

во-вторых, в вашем запросе всего один единственный фильтрующий предикат: o.orderdate+o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'. да и тот вы записали так, что полностью исключили возможность использования индексов (если таковые по полям o.orderdate / o.ordertime имеются...)

...

Рейтинг:

0 / 0

26.07.2018, 04:17

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679355

Щукина Анна

Участник

Сообщения: 1 496

Рейтинг: 0 / 0

KillerProg,

в целом, с учетом замечаний, ваш запрос можно переписать как-то так:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

select od.productid
     , max(p.productname) as productname --- можно выкинуть MAX, но добавить поле p.productname в предложение GROUP BY
     , sum(od.quantity) as qty
     , sum(od.quantity*od.unitprice) as proiz
  from ordersdetails od
 inner join orders o on o.id = od.ordid
 inner join products p on od.productid = p.id
 where o.orderdate between '01.01.2017' and '26.07.2018' -- возможно, подхватится индекс по  o.orderdate, если такой есть
   and o.orderdate + o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'
--    and o.itemkch = 0
 group by od.productid

...

Рейтинг:

0 / 0

26.07.2018, 04:25

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679356

Щукина Анна

Участник

Сообщения: 1 496

Рейтинг: 0 / 0

KillerProg

Код: sql

1.
2.
3.

...
                  where o.orderdate+o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'
...

если бы не эта минута в условии (кстати, а зачем оно там?), то всё ваше фильтрующее условие можно было бы записать в таком виде:

Код: sql

1.
2.

 where o.orderdate >= '01.01.2017'
   and o.orderdate < '26.07.2018'

...

Рейтинг:

0 / 0

26.07.2018, 04:32

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679418

KreatorXXI

Участник

Откуда: Москва

Сообщения: 1 106

Рейтинг: 0 / 0

KillerProg,

А зачем здесь CTE? Ради наименования товара? Убрать. Group by сделать по двум полям. Индекс по дате есть? План из Эксперта, пожалуйста, в студию.

...

Рейтинг:

0 / 0

26.07.2018, 09:47

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679420

Щукина Анна

Участник

Сообщения: 1 496

Рейтинг: 0 / 0

KreatorXXI,

"не читай форум, сразу баян пости"(с) с просторов интернета...

...

Рейтинг:

0 / 0

26.07.2018, 09:53

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679425

DarkMaster

Участник

Откуда: Donetsk,Ukraine

Сообщения: 6 681

Рейтинг: 0 / 0

Щукина Анна,

Зачем это оставили?

Код: sql

and o.orderdate + o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'

Orderdate + ordertime не особо нужно, т.к. первое условие по orderdate уже обрежет ненужное. Ну и индекс подхватится по time, если есть.

Код: sql

and o.ordertime between '00:01:00' and '23:59:00'

...

Рейтинг:

0 / 0

26.07.2018, 10:01

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679442

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

DarkMaster,

это не эквивалент к сожалению. Если есть индекс по orderdate, то можно сделать так

Код: sql

1.
2.

where o.orderdate between '01.01.2017' and '25.07.2018'
  and o.orderdate+o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'

в прочем уже советовали

Щукина Аннаво-первых, зачем дважды ходить в таблицу products?

иногда в этом есть смысл для уменьшения ширины резалтсета для сортировки, но это надо делать только если productname очень длинное. Или ещё один вариант чтобы хватался индекс при group by. В данном случае скорее всего не надо

...

Рейтинг:

0 / 0

26.07.2018, 10:21

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679445

m7m

Участник

Откуда: Украина, Мариуполь

Сообщения: 1 481

Рейтинг: 0 / 0

DarkMasterЩукина Анна,

Зачем это оставили?

Код: sql

and o.orderdate + o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'

Код: sql

and o.ordertime between '00:01:00' and '23:59:00'

Затем что оно все-же нужно, ну или условие переписать на что-то такое

Код: sql

1.
2.
3.

    (o.orderdate=date '01.01.2017' and o.ordertime >=time '00:01:00')
or (o.orderdate between '02.01.2017' and '24.07.2018')
or (o.orderdate=date '25.07.2018' and o.ordertime <=time '23:59:00')

...

Рейтинг:

0 / 0

26.07.2018, 10:23

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679446

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

KillerProg,

я бы попробвал вот так

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

with tm as (
    select 
        od.productid,
        sum(od.quantity) as qty, 
        sum(od.quantity * od.unitprice) as proiz
    from ordersdetails od 
       join orders o on o.id = od.ordid
    where o.orderdate between '01.01.2017' and '25.07.2018'
        and o.orderdate+o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'
  --    and o.itemkch = 0
    group by od.productid
) 
select
     t.productid,
     p.productname,
     t.qty as qty,
     t.proiz as sm
from tm t 
  left join products p on p.id = t.productid

...

Рейтинг:

0 / 0

26.07.2018, 10:27

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39679571

Щукина Анна

Участник

Сообщения: 1 496

Рейтинг: 0 / 0

DarkMasterЩукина Анна,

Зачем это оставили?

Код: sql

and o.orderdate + o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'

если внимательно посмотреть на исходное условие от ТС, то он там исключает первую и последнюю минуты интервала.

про неэквивалентность условия исходному - уже писали...
авторOrderdate + ordertime не особо нужно, т.к. первое условие по orderdate уже обрежет ненужное. Ну и индекс подхватится по time, если есть.

Код: sql

and o.ordertime between '00:01:00' and '23:59:00'

...

Рейтинг:

0 / 0

26.07.2018, 12:44

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680092

KillerProg

Гость

Сделал следующий запрос, с учетом Ваших рекомендаций.

Сделал всю выборку из базы данных

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.

select od.productid
     , max(p.productname) as productname 
     , sum(od.quantity) as qty
     , sum(od.quantity*od.unitprice) as proiz
  from ordersdetails od
inner join orders o on o.id = od.ordid
inner join products p on od.productid = p.id
 group by od.productid

План запроса следующий:

План
PLAN JOIN (OD ORDER FK_ORDERSDETAILS_1, P INDEX (PK_PRODUCTS), O INDEX (PK_ORDERS))

------ Информация о производительности ------
Время подготовки запроса = 32ms
Время выполнения запроса = 9s 984ms
Среднее время на получение одной записи = 399,36 ms
Current memory = 38 644 368
Max memory = 104 930 256
Memory buffers = 2 048
Reads from disk to cache = 114 442
Writes from cache to disk = 20
Fetches from cache = 0

---------------------------

То есть получается запрос выполняется 9 секунд, это конечно меньше того что было.

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

...

Рейтинг:

0 / 0

27.07.2018, 11:51

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680118

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

KillerProgА вообще это нормально что данный запрос выполняется столько времени (9 секунд)?

На холодной базе - да. Но, похоже, у тебя кэш маловат и индексы в него не влазят. Проверь
по gstat.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2018, 12:24

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680127

KreatorXXI

Участник

Откуда: Москва

Сообщения: 1 106

Рейтинг: 0 / 0

KillerProg,

А большая таблица ordersdetails? Что-то мне подсказывает, что большая. Если навесить фильтр по датам, то результат будет другим.

...

Рейтинг:

0 / 0

27.07.2018, 12:33

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680134

KillerProg

Гость

Dimitry Sibiryakov,

А как это сделать по gstat? (извиняюсь но что то не припомню как это сделать)

...

Рейтинг:

0 / 0

27.07.2018, 12:39

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680135

KillerProg

Гость

KreatorXXI,

В таблице orderdetails 330 000 записей

...

Рейтинг:

0 / 0

27.07.2018, 12:39

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680136

KillerProg

Гость

Dimitry Sibiryakov,

И как увеличить кэш?

...

Рейтинг:

0 / 0

27.07.2018, 12:40

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680143

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Dimitry Sibiryakov,

что то-мне подсказывает что у него классик 2.5. Так что не факт что кеш можно дальше увеличивать.

KillerProg,

забавно ты запрос переделал, т.е. фильтрация по датам больше не нужна читаем вообще всё.
Попробуй отключить навигацию по индексу

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.

select od.productid+0 as productid,
     , max(p.productname) as productname 
     , sum(od.quantity) as qty
     , sum(od.quantity*od.unitprice) as proiz
  from ordersdetails od
inner join orders o on o.id = od.ordid
inner join products p on od.productid = p.id
 group by od.productid+0

...

Рейтинг:

0 / 0

27.07.2018, 12:46

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680147

KillerProg

Гость

Симонов Денис,

Фильтрация по дате и времени нужна, это я просто проверить решил без этой фильтрации

...

Рейтинг:

0 / 0

27.07.2018, 12:48

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680148

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

KillerProgА как это сделать по gstat?

Если запустить gstat с правильными ключами, он покажет сколько страниц занимает тот или
иной индекс.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2018, 12:48

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680154

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

KillerProg,

в IB Expert правой клавишей мыши по табличке щёлкаешь и далее на пункт меню "получить статистику для выделенных таблиц"

...

Рейтинг:

0 / 0

27.07.2018, 12:54

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39680415

KillerProg

Гость

Симонов ДенисKillerProg,

в IB Expert правой клавишей мыши по табличке щёлкаешь и далее на пункт меню "получить статистику для выделенных таблиц"

Что то такого пункта меню я не вижу

...

Рейтинг:

0 / 0

27.07.2018, 21:08

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681291

akrush

Участник

Откуда: Киев, Украина

Сообщения: 367

Рейтинг: 0 / 0

KillerProg,
Меню "Службы" - "Сатистика БД" - перетянуть нужную БД и будет статистика

...

Рейтинг:

0 / 0

30.07.2018, 21:26

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681333

KillerProg

Гость

Вот что получилось

Это текстовая информация, также в прилагаемом файле изображение для индексов

авторDatabase "d:\programm\DataBase\DATAFOOD.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 50671839
Page size 16384
ODS version 11.1
Oldest transaction 50502737
Oldest active 50502738
Oldest snapshot 50502738
Next transaction 50671460
Bumped transaction 1
Sequence number 0
Next attachment ID 13621
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Dec 29, 2016 0:04:48
Attributes force write

Variable header data:
*END*

Database file sequence:
File d:\programm\DataBase\DATAFOOD.FDB is the only file

Analyzing database pages ...
CATEGORIES (133)
Primary pointer page: 154, Index root page: 155
Data pages: 1, data page slots: 1, average fill: 5%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index CATEGORIES_IDX1 (1)
Depth: 1, leaf buckets: 1, nodes: 15
Average data length: 0.07, total dup: 14, max dup: 14
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_CATEGORIES (0)
Depth: 1, leaf buckets: 1, nodes: 15
Average data length: 1.13, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

CUSTOMERS (131)
Primary pointer page: 148, Index root page: 149
Data pages: 163, data page slots: 163, average fill: 76%
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 154
80 - 99% = 8

Index CUSTOMERS_IDX1 (1)
Depth: 2, leaf buckets: 16, nodes: 27868
Average data length: 3.29, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 3
80 - 99% = 13

Index PK_CUSTOMERS (0)
Depth: 2, leaf buckets: 9, nodes: 27868
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 8

DATEWORK (140)
Primary pointer page: 773, Index root page: 774
Data pages: 4, data page slots: 4, average fill: 58%
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 3
80 - 99% = 0

Index PK_DATEWORK (0)
Depth: 1, leaf buckets: 1, nodes: 845
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

DOSTAVKA (141)
Primary pointer page: 1056, Index root page: 1057
Data pages: 0, data page slots: 0, average fill: 0%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_DOSTAVKA (0)
Depth: 1, leaf buckets: 1, nodes: 0
Average data length: 0.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

EMPLOYEES (132)
Primary pointer page: 151, Index root page: 152
Data pages: 1, data page slots: 1, average fill: 30%
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_EMPLOYEES (0)
Depth: 1, leaf buckets: 1, nodes: 25
Average data length: 1.20, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

FACILITY (129)
Primary pointer page: 140, Index root page: 141
Data pages: 1, data page slots: 1, average fill: 1%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_FACILITY (0)
Depth: 1, leaf buckets: 1, nodes: 4
Average data length: 1.25, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

JOURNALCALL (139)
Primary pointer page: 192, Index root page: 193
Data pages: 2166, data page slots: 2166, average fill: 80%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 99
80 - 99% = 2067

Index JOURNALCALL_IDX1 (0)
Depth: 3, leaf buckets: 1029, nodes: 309826
Average data length: 32.05, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 9
20 - 39% = 0
40 - 59% = 196
60 - 79% = 592
80 - 99% = 232

Index JOURNALCALL_IDX2 (1)
Depth: 2, leaf buckets: 130, nodes: 309826
Average data length: 0.31, total dup: 280388, max dup: 540
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 9
60 - 79% = 77
80 - 99% = 44

ORDERCOURIER (138)
Primary pointer page: 186, Index root page: 187
Data pages: 115, data page slots: 115, average fill: 38%
Fill distribution:
0 - 19% = 12
20 - 39% = 67
40 - 59% = 21
60 - 79% = 15
80 - 99% = 0

Index FK_ORDERCOURIER_1 (1)
Depth: 2, leaf buckets: 7, nodes: 15742
Average data length: 0.00, total dup: 15694, max dup: 5602
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 4
60 - 79% = 1
80 - 99% = 1

Index FK_ORDERCOURIER_2 (2)
Depth: 2, leaf buckets: 10, nodes: 15421
Average data length: 1.27, total dup: 8, max dup: 2
Fill distribution:
0 - 19% = 0
20 - 39% = 3
40 - 59% = 5
60 - 79% = 0
80 - 99% = 2

Index PK_ORDERCOURIER (0)
Depth: 2, leaf buckets: 11, nodes: 15286
Average data length: 1.19, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 5
40 - 59% = 2
60 - 79% = 2
80 - 99% = 1

ORDERS (134)
Primary pointer page: 157, Index root page: 158
Data pages: 1130, data page slots: 1130, average fill: 89%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 13
80 - 99% = 1117

Index ORDERS_IDX1 (1)
Depth: 2, leaf buckets: 45, nodes: 101114
Average data length: 0.28, total dup: 73247, max dup: 3204
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 17
60 - 79% = 22
80 - 99% = 6

Index ORDERS_IDX2 (2)
Depth: 2, leaf buckets: 55, nodes: 104914
Average data length: 0.00, total dup: 104909, max dup: 95325
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 50
60 - 79% = 4
80 - 99% = 1

Index ORDERS_IDX3 (3)
Depth: 2, leaf buckets: 137, nodes: 101114
Average data length: 10.49, total dup: 1, max dup: 1
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 6
60 - 79% = 101
80 - 99% = 30

Index ORDERS_IDX4 (5)
Depth: 2, leaf buckets: 33, nodes: 101114
Average data length: 0.01, total dup: 100598, max dup: 498
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 8
60 - 79% = 0
80 - 99% = 24

Index ORDERS_IDX5 (4)
Depth: 2, leaf buckets: 59, nodes: 101114
Average data length: 2.05, total dup: 106, max dup: 1
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 10
60 - 79% = 12
80 - 99% = 37

Index PK_ORDERS (0)
Depth: 2, leaf buckets: 39, nodes: 101114
Average data length: 1.05, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 3
20 - 39% = 0
40 - 59% = 2
60 - 79% = 0
80 - 99% = 34

ORDERSDETAILS (135)
Primary pointer page: 160, Index root page: 161
Data pages: 1722, data page slots: 1722, average fill: 71%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 1721
80 - 99% = 0

Index FK_ORDERSDETAILS_1 (1)
Depth: 2, leaf buckets: 162, nodes: 332778
Average data length: 0.00, total dup: 332570, max dup: 40665
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 114
60 - 79% = 27
80 - 99% = 21

Index FK_ORDERSDETAILS_2 (2)
Depth: 2, leaf buckets: 120, nodes: 332778
Average data length: 0.32, total dup: 231669, max dup: 26
Fill distribution:
0 - 19% = 5
20 - 39% = 0
40 - 59% = 24
60 - 79% = 0
80 - 99% = 91

Index ORDERSDETAILS_IDX1 (4)
Depth: 2, leaf buckets: 161, nodes: 332778
Average data length: 0.00, total dup: 332755, max dup: 266627
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 129
60 - 79% = 1
80 - 99% = 31

Index ORDERSDETAILS_IDX2 (3)
Depth: 2, leaf buckets: 163, nodes: 332778
Average data length: 0.01, total dup: 332725, max dup: 50716
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 122
60 - 79% = 17
80 - 99% = 24

Index PK_ORDERSDETAILS (0)
Depth: 2, leaf buckets: 117, nodes: 332778
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 116

PRODUCTS (130)
Primary pointer page: 144, Index root page: 146
Data pages: 3, data page slots: 3, average fill: 68%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 2

Index FK_PRODUCTS_1 (2)
Depth: 1, leaf buckets: 1, nodes: 348
Average data length: 0.05, total dup: 333, max dup: 101
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_PRODUCTS (0)
Depth: 1, leaf buckets: 1, nodes: 211
Average data length: 1.01, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PRODUCTS_IDX1 (1)
Depth: 1, leaf buckets: 1, nodes: 212
Average data length: 0.03, total dup: 207, max dup: 67
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

UNITSTORAGE (137)
Primary pointer page: 182, Index root page: 183
Data pages: 1, data page slots: 1, average fill: 0%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_UNITSTORAGE (0)
Depth: 1, leaf buckets: 1, nodes: 1
Average data length: 2.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

USERS (136)
Primary pointer page: 163, Index root page: 164
Data pages: 1, data page slots: 1, average fill: 4%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_USERS (0)
Depth: 1, leaf buckets: 1, nodes: 8
Average data length: 1.13, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

...

Рейтинг:

0 / 0

30.07.2018, 23:35

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681546

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

KillerProg,

зачем это всё сюда вываливать? да еще без тега spoiler.

KillerProgOldest active 50502738
Next transaction 50671460
какая-то активная транзакция уже дня два живет.

...

Рейтинг:

0 / 0

31.07.2018, 13:23

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681571

Ivan_Pisarevsky

Участник

Откуда: НН

Сообщения: 9 563

Рейтинг: 0 / 0

kdvда еще без тега spoiler.На сегодня по спойлер все сунул, там действительно достаточно было только хидера. В следующий раз сам, кнопочка "прочее"->"spoiler".

...

Рейтинг:

0 / 0

31.07.2018, 14:15

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681768

KillerProg

Гость

Извинияюсь товарищи, немного запарился...

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

...

Рейтинг:

0 / 0

31.07.2018, 21:34

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681769

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

KillerProg,

21603422 пробовал?

...

Рейтинг:

0 / 0

31.07.2018, 21:38

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681774

KillerProg

Гость

Симонов ДенисKillerProg,

21603422 пробовал?

Проверил вот такая информацию выдает

автор
План
PLAN JOIN (SORT (JOIN (T O INDEX (ORDERS_IDX5, ORDERS_IDX4), T OD INDEX (FK_ORDERSDETAILS_2))), P INDEX (PK_PRODUCTS))

------ Информация о производительности ------
Время подготовки запроса = 296ms
Время выполнения запроса = 3s 650ms
Среднее время на получение одной записи = 146,00 ms
Current memory = 39 801 032
Max memory = 108 127 880
Memory buffers = 2 048
Reads from disk to cache = 6 257
Writes from cache to disk = 10
Fetches from cache = 0

В принципе стало лучше

...

Рейтинг:

0 / 0

31.07.2018, 22:03

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681779

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

KillerProg,

можно попробовать немного увеличить TempCacheLimit
Хотя думаю лучше уже не будет

...

Рейтинг:

0 / 0

31.07.2018, 22:20

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681794

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Кеш можно увеличить

...

Рейтинг:

0 / 0

31.07.2018, 23:22

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681796

KillerProg

Гость

hvlad,

TempCacheLimit ?

...

Рейтинг:

0 / 0

31.07.2018, 23:32

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39681797

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

KillerProg,

TempCacheLimit это память под сортировку (которая в плане как SORT отображается)
а страничный кеш это DefaultDbCachePages

...

Рейтинг:

0 / 0

31.07.2018, 23:34

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39682519

KreatorXXI

Участник

Откуда: Москва

Сообщения: 1 106

Рейтинг: 0 / 0

KillerProgИзвинияюсь товарищи, немного запарился...

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

А зачем в запросе таблица orders?

...

Рейтинг:

0 / 0

02.08.2018, 12:35

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39682820

KillerProg

Гость

KreatorXXI,

В этой таблице указан заказ, и дата и время заказа

...

Рейтинг:

0 / 0

02.08.2018, 20:56

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39682857

Старый плюшевый мишка

Участник

Сообщения: 1 259

Рейтинг: 0 / 0

KillerProgKreatorXXI,

В этой таблице указан заказ, и дата и время заказа

1. Может я невнимателен, но не увидел кто такие IDX тыры-пыры на orders. Дальше всё в предположении, что на эту таблицу всегда накладываются условия.
2. Если на orders нет индекса по дате, создать таковой. Как, впрочем, и по всем селективным полям, на которые накладываются условия фильтрации. Если условия практически всегда применяются по нескольким полям, скажем, по паре дата-клиент, неплох будет и соответствующий композит.
3. Не мудрствовать лукаво, строить запрос из простых джойнов, как Рустам учил.
4. Сделать при помощи +0 таблицу orders ведущей в запросе, ordersdetail ведомой, products ведомой от ordersdetail.
5. Наслаждаться жизнью.
6. Если скорость запроса нужна просто ядерная, и интервалы дат фиксированные, типа помесячно, подумать о таблице хранимых агрегатов на сетке этих периодов.

Если неточно написал названия таблиц, прошу пардону, тырнет сегодня на даче 2G спотыкаясь, перечитывать всё влом.

...

Рейтинг:

0 / 0

02.08.2018, 22:45

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39682865

KillerProg

Гость

Старый плюшевый мишка,

У меня есть отдельные индексы по orderdate и ordertime

...

Рейтинг:

0 / 0

02.08.2018, 23:41

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39682947

KreatorXXI

Участник

Откуда: Москва

Сообщения: 1 106

Рейтинг: 0 / 0

KillerProg,

Возвращаемся взад. Если в запросе есть связка с orders, то нужно обязательно наложить условия фильтрации по дате, например. С такими условиями долго?
Если нужно посмотреть всё, то orders не нужен. Для проверки вообще сделай запрос только по ordersdetail, с суммированием, как положено. Давай посмотрим какой будет результат с одной таблицей в ~300 тыс. записей.

...

Рейтинг:

0 / 0

03.08.2018, 10:23

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683409

KillerProg

Гость

Сделал запрос отдельно , без таблицы orders.

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.

select
     odetail.productid,
     p.productname,
     sum(odetail.quantity) as qty,
     sum(odetail.quantity * odetail.unitprice) as sm
from ordersdetails odetail
  left join products p on p.id = odetail.productid
group by odetail.productid, p.productname

План запроса вот:

автор
План
PLAN SORT (JOIN (ODETAIL NATURAL, P INDEX (PK_PRODUCTS)))

------ Информация о производительности ------
Время подготовки запроса = 31ms
Время выполнения запроса = 4s 571ms
Среднее время на получение одной записи = 182,84 ms
Current memory = 38 278 720
Max memory = 107 309 016
Memory buffers = 2 048
Reads from disk to cache = 5 121
Writes from cache to disk = 6
Fetches from cache = 0

То есть выполняется 4 с поливной секунды.

А вообще возможно ли ускорить как нибудь этот запрос?

Что то я уже запарился....)))

...

Рейтинг:

0 / 0

05.08.2018, 10:48

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683414

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

KillerProg,

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

И кстати мы так и не увидели версию сервера. Судя по ODS у тебя 2.1.x

...

Рейтинг:

0 / 0

05.08.2018, 11:12

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683501

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

KillerProgА вообще возможно ли ускорить как нибудь этот запрос?
диском-то у тебя всё нормально? А то 5 тысяч чтений с диска и группировка за 4 сек - это как-то подозрительно.
hd tune, crystalDiskMark ?

...

Рейтинг:

0 / 0

05.08.2018, 20:42

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683504

KillerProg

Гость

[quot kdv]KillerProgА то 5 тысяч чтений с диска и группировка за 4 сек - это как-то подозрительно.
hd tune, crystalDiskMark ?

Я не совсем понял?

...

Рейтинг:

0 / 0

05.08.2018, 21:53

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683508

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

KillerProgЯ не совсем понял?
ээээ, производительность СУБД определятся в первую очередь диском, уже потом памятью и процессором.
По данным page reads и времени запроса, я предполагаю, что производительность диска не очень высокая.
И предложил ПОМЕРЯТЬ её каким-нибудь предложенным инструментом.

...

Рейтинг:

0 / 0

05.08.2018, 22:38

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683596

KreatorXXI

Участник

Откуда: Москва

Сообщения: 1 106

Рейтинг: 0 / 0

KillerProg,

Вообще многовато. А если вообще выкинуть таблицу products из запроса? Нужно посмотреть скорость на одной таблице. Или смысла уже нет? А, народ? Просто посмотрел у себя (таблица ~180000 записей), запрос с агрегатами по ней - 733ms. Но у меня FB3.0SS.

...

Рейтинг:

0 / 0

06.08.2018, 10:09

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683677

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

KreatorXXI,

дык на троешном SS ты всю таблицу и индекс в страничный кеш можешь легко запихнуть. Да и память под сортировки у тебя небось побольше

...

Рейтинг:

0 / 0

06.08.2018, 12:57

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683763

KreatorXXI

Участник

Откуда: Москва

Сообщения: 1 106

Рейтинг: 0 / 0

У меня, кстати, такая статистика:
------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 749ms
Среднее время на получение одной записи = 1,75 ms
Current memory = 68 457 856
Max memory = 153 802 656
Memory buffers = 12 000
Reads from disk to cache = 83 743
Writes from cache to disk = 1
Чтений из кэша = 505 902

Много чтений из кэша, у ТС - 0. Это влияет? Если у ТС FB2.1 и реально улучшить ничего нельзя, то в топку? Переходить на третью версию?

...

Рейтинг:

0 / 0

06.08.2018, 14:58

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683764

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

KreatorXXIу ТС - 0. Это влияет?
скорее всего это глюк ibe, или он старый.
фетчей из кэша не может быть 0.

...

Рейтинг:

0 / 0

06.08.2018, 15:00

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683766

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

KreatorXXIреально улучшить ничего нельзя, то в топку? Переходить на третью версию?
"переходить" с 2.0 на 2.1, с 2.1 на 2.5, или с 2.5 на 3.0 можно только с благословения разработчиков. В остальных случаях результат самостоятельного перехода может стать фатальным.

...

Рейтинг:

0 / 0

06.08.2018, 15:01

| Ответить | Цитировать | Написать

Долго выполняется запрос

#39683779

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

kdvKreatorXXIу ТС - 0. Это влияет?
скорее всего это глюк ibe, или он старый.
фетчей из кэша не может быть 0.

этот глюк есть и в последних версиях IBE

...

Рейтинг:

0 / 0

06.08.2018, 15:21

| Ответить | Цитировать | Написать

49 сообщений из 49, показаны все 2 страниц

все

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Долго выполняется запрос

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=40&tid=1561026]:	0ms
get settings:	10ms
get forum list:	14ms
check forum access:	2ms
check topic access:	2ms
track hit:	62ms
get topic data:	10ms
get forum data:	2ms
get page messages:	80ms
get tp. blocked users:	1ms
others:	14ms

total:	197ms