Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Долго выполняется запрос / 25 сообщений из 49, страница 1 из 2
  1  все
26.07.2018, 00:13
    #39679327
KillerProg
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, 04:17
    #39679354
Щукина Анна
Щукина Анна
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
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:25
    #39679355
Щукина Анна
Щукина Анна
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
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:32
    #39679356
Щукина Анна
Щукина Анна
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
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, 09:47
    #39679418
KreatorXXI
KreatorXXI
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KillerProg,

А зачем здесь CTE? Ради наименования товара? Убрать. Group by сделать по двум полям. Индекс по дате есть? План из Эксперта, пожалуйста, в студию.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 09:53
    #39679420
Щукина Анна
Щукина Анна
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KreatorXXI,

"не читай форум, сразу баян пости"(с) с просторов интернета...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 10:01
    #39679425
DarkMaster
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
Щукина Анна,

Зачем это оставили?
Код: sql
1.
and o.orderdate + o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'



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

Код: sql
1.
and o.ordertime between '00:01:00' and '23:59:00'
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.07.2018, 10:21
    #39679442
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
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:23
    #39679445
m7m
m7m
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
DarkMasterЩукина Анна,

Зачем это оставили?
Код: sql
1.
and o.orderdate + o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'




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

Код: sql
1.
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:27
    #39679446
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
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, 12:44
    #39679571
Щукина Анна
Щукина Анна
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
DarkMasterЩукина Анна,

Зачем это оставили?
Код: sql
1.
and o.orderdate + o.ordertime between '01.01.2017 00:01:00' and '25.07.2018 23:59:00'

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



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

Код: sql
1.
and o.ordertime between '00:01:00' and '23:59:00'
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 11:51
    #39680092
KillerProg
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, 12:24
    #39680118
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KillerProgА вообще это нормально что данный запрос выполняется столько времени (9 секунд)?

На холодной базе - да. Но, похоже, у тебя кэш маловат и индексы в него не влазят. Проверь
по gstat.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 12:33
    #39680127
KreatorXXI
KreatorXXI
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KillerProg,

А большая таблица ordersdetails? Что-то мне подсказывает, что большая. Если навесить фильтр по датам, то результат будет другим.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 12:39
    #39680134
KillerProg
KillerProg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
Dimitry Sibiryakov,

А как это сделать по gstat? (извиняюсь но что то не припомню как это сделать)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 12:39
    #39680135
KillerProg
KillerProg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KreatorXXI,

В таблице orderdetails 330 000 записей
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 12:40
    #39680136
KillerProg
KillerProg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
Dimitry Sibiryakov,

И как увеличить кэш?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 12:46
    #39680143
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
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:48
    #39680147
KillerProg
KillerProg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
Симонов Денис,

Фильтрация по дате и времени нужна, это я просто проверить решил без этой фильтрации
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 12:48
    #39680148
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KillerProgА как это сделать по gstat?

Если запустить gstat с правильными ключами, он покажет сколько страниц занимает тот или
иной индекс.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 12:54
    #39680154
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KillerProg,

в IB Expert правой клавишей мыши по табличке щёлкаешь и далее на пункт меню "получить статистику для выделенных таблиц"
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.07.2018, 21:08
    #39680415
KillerProg
KillerProg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
Симонов ДенисKillerProg,

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

Что то такого пункта меню я не вижу
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.07.2018, 21:26
    #39681291
akrush
akrush
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KillerProg,
Меню "Службы" - "Сатистика БД" - перетянуть нужную БД и будет статистика
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.07.2018, 23:35
    #39681333
KillerProg
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
| Ответить | Цитировать | Написать  
31.07.2018, 13:23
    #39681546
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Долго выполняется запрос
KillerProg,

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

KillerProgOldest active 50502738
Next transaction 50671460
какая-то активная транзакция уже дня два живет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Долго выполняется запрос / 25 сообщений из 49, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 571ms
Закрыть
start [/forum/topic.php?fid=40&mobile=1&tid=1561026]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 166ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 311ms
total:  571ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]