ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Долго выполняется запрос
25 сообщений из 49, страница 1 из 2
  1  все
Долго выполняется запрос
    #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, 00:13
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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:17
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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:25
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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, 04:32
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #39679418
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
KillerProg,

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

"не читай форум, сразу баян пости"(с) с просторов интернета...
...
Рейтинг: 0 / 0
26.07.2018, 09:53
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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:01
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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:21
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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:23
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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, 10:27
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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
26.07.2018, 12:44
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #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, 11:51
| Ответить | Цитировать | Написать  
Долго выполняется запрос
    #39680118
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
KillerProgА вообще это нормально что данный запрос выполняется столько времени (9 секунд)?

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

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

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

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

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

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

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

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


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