ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Создание оптимальных индексов
25 сообщений из 46, страница 1 из 2
  1  все
Создание оптимальных индексов
    #33406437
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Есть вопрос по оптимизации. Как создать индекс для конкретного запроса? Коков алгоритм действий, куда смотреть?

Informix Dynamic Server 2000 Version 9.21.HC3 стоит под вебом http://www.micex.ru/online/stock/archive/
Типичный запрос
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
   SELECT FIRST  20  h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'), h.*
    FROM ngcb_hist h, secs s
    WHERE h.id IN
    (SELECT id FROM secsLI WHERE idSecList='INDEXSECS'
      AND idSector='securies' AND sec_publ= 1 )
    AND h.pos>= 6543 
    AND h.publ= 2 
    AND h.id=s.id
    AND h.trdate=mdy( 7 , 13 , 2005 )
-- мигает
    AND h.numtrades> 0 
-- мигает
    AND h.boardGroup IN
    (SELECT boardGroup FROM boardSelect WHERE boardGroupSet='repo|smal|'
       AND idSector='securies')
-- мигает
    AND s.idSector='securies'
    ORDER BY  1
ngcb_hist - сотни тысяч записей, secs - тысячи
то что находится между комментариями "-- мигает" - иногда присутствует в запросе, иногда - нет.

Я делал так - создавал все кучу индексов на ngcb_hist по всем полям, участвующем в запросе (всевозможные перестановки id, trdate, boardGroup, numtrades), делал апдейт статистикс хай, запускал запрос с експлайном и смотрел какие индексы использует информикс. Оставались несколько индексов, их-то и переносил в боевую БД.

Понимаю, что шел экстенсивным путем, но интенсивного ниасилил. Все эти рассуждения о селективности не смог применить в реальной ситуации - как не делаю, информикс не хочет использовать мои индексы :( Чего-то я недопонимаю...

Может многоуважаемое сообщество подскажет _правильный_ путь создания оптимальных индексов для конкретных запросов? Кто как делает?
...
Рейтинг: 0 / 0
29.11.2005, 16:35
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33406538
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубый...
Код: plaintext
1.
   SELECT FIRST  20  h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'),     ORDER BY  1

мало информации (сколько строк возратится без FIRST 20), планы хотя-бы.

дурацкое предположение:
SELECT /*+ first_rows*/ FIRST 20 h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'),
и индекс по h.pos
...
Рейтинг: 0 / 0
29.11.2005, 17:01
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33406632
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
QUERY:
------
SELECT FIRST  20  h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'), h.*
    FROM ngcb_hist h, secs s
    WHERE h.id IN
    (SELECT id FROM secsLI WHERE idSecList='INDEXSECS'
      AND idSector='securies' AND sec_publ= 1 )
    AND h.pos>= 6543 
    AND h.publ= 2 
    AND h.id=s.id
    AND h.trdate=mdy( 7 , 13 , 2005 )
    AND h.numtrades> 0 
    AND s.idSector='securies'
    ORDER BY  1 

Estimated Cost:  3 
Estimated # of Rows Returned:  1 
Temporary Files Required For: Order By  

   1 ) denn.h: INDEX PATH

        Filters: (denn.h.publ =  2  AND denn.h.pos >=  6543  ) 

    ( 1 ) Index Keys: trdate id boardgroup numtrades   (Key-First)  (Serial, fragments: ALL)
        Lower Index Filter: (denn.h.trdate =  13 - 07 - 2005  AND denn.h.id = ANY <subquery> ) 
        Key-First Filters:  (denn.h.numtrades >  0  )

   2 ) denn.s: INDEX PATH

    ( 1 ) Index Keys: idsector id   (Serial, fragments: ALL)
        Lower Index Filter: (denn.h.id = denn.s.id AND denn.s.idsector = 'securies' ) 
NESTED LOOP JOIN

    Subquery:
    ---------
    Estimated Cost:  3 
    Estimated # of Rows Returned:  13 

       1 ) informix.secsli: INDEX PATH

            Filters: informix.secsli.sec_publ =  1  

        ( 1 ) Index Keys: idsector idseclist   (Serial, fragments: ALL)
            Lower Index Filter: (informix.secsli.idseclist = 'INDEXSECS' AND informix.secsli.idsector = 'securies' )

без FIRST запрос вернет порядка 1000 записей. Видно что в данном случае планировщик использовал индекс (trdate, id, boardgroup, numtrades)

Я не про этот конкретный запрос. У меня таких штук 20, на разных таблицах, с разным соотношением distinct id, distinct boardgroup, distinct numtrades...

Какой _правильный_ алгоритм построения оптимального индекса? На что обращать внимание, как определять порядок колонок в индексе?
...
Рейтинг: 0 / 0
29.11.2005, 17:31
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33406779
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Журавлев Денис и индекс по h.pos

это для order by? по моему он будет бесполезен при связывании нескольких таблиц. ведь отфильрованный резалт сет пишется в tmpdb, а толко потом упорядочивается. вот если б одна табличка была...
...
Рейтинг: 0 / 0
29.11.2005, 18:16
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33407078
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубый Журавлев Денис и индекс по h.pos

это для order by? по моему он будет бесполезен при связывании нескольких таблиц. ведь отфильрованный резалт сет пишется в tmpdb, а толко потом упорядочивается. вот если б одна табличка была...
:)

SELECT /*+ first_rows*/ FIRST 20 h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'),
...
Рейтинг: 0 / 0
29.11.2005, 20:56
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33407517
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубый
без FIRST запрос вернет порядка 1000 записей. Видно что в данном случае планировщик использовал индекс (trdate, id, boardgroup, numtrades)
Судя по Filters: (denn.h.publ = 2 AND denn.h.pos >= 6543 ) более эффективным был бы trdate, pos.

Сугубыйh.id IN (SELECT id FROM secsLI WHERE idSecList='INDEXSECS'
AND idSector='securies' AND sec_publ=1)Видимо информикс думает что SELECT id FROM secsLI вернет много строк, кстати у меня есть подозрение в этом случае лучше не IN, а EXSIST, и вообще переделать подзапрос в джойн, если он возвращает более одной строки.

СугубыйЯ не про этот конкретный запрос. У меня таких штук 20, на разных таблицах, с разным соотношением distinct id, distinct boardgroup, distinct numtrades...
Возможно надо несколько индексов, надо цель оптимизации сначала определить, а потом ставить задачи.
СугубыйКакой _правильный_ алгоритм построения оптимального индекса? На что обращать внимание, как определять порядок колонок в индексе?Оптимальных индексов не бывает, нужен критерий оптимальности.
Самое важное это правильный порядок соединения таблиц, индексы на втором месте.

Про порядок колонок: индекс может использоваться если его первые поля были в запросе.
в запросе where trdate =?
может использоваться индекс (trdate, id)
а (id, trdate) не может
но (id, trdate) может использоваться при where trdate = ? and id =?
Если id внешний ключ, то возможно нужен индекс где оно первое.
Если h.numtrades>0 редко (отсекаем выходные?), то его можно не включать в индексы.
Если во многих запросах есть h.pos>=? AND h.publ=? AND h.trdate=?, то возможно нужен trdate, publ, pos, но все зависит от селективности. Например если publ всегда =2, то в индекс его можно не включать. Но если селективность высокая или есть исключения, то его можно включить.

Бд на мой вкус криво спроектирована:
FROM secs s WHERE s.idSector='securies'
FROM secsLI WHERE idSector='securies'
FROM boardSelect WHERE idSector='securies'
...
Рейтинг: 0 / 0
30.11.2005, 09:38
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408495
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Журавлев Денис
:)

SELECT /*+ first_rows*/ FIRST 20 h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'),

ой, а как такие большие буквы сделать? ;)))


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
QUERY:        (FIRST_ROWS OPTIMIZATION)

------
SELECT /*+ first_rows*/ FIRST  20  h.pos, h.id,
h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'), h.*
    FROM ngcb_hist h, secs s
    WHERE h.id IN
    (SELECT id FROM secsLI WHERE idSecList='INDEXSECS'
      AND idSector='securies' AND sec_publ= 1 )
    AND h.pos>= 6543 
    AND h.publ= 2 
    AND h.id=s.id
    AND h.trdate=mdy( 7 , 13 , 2005 )
    AND h.numtrades> 0 
    AND s.idSector='securies'
    ORDER BY  1 

DIRECTIVES FOLLOWED: 
FIRST_ROWS 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost:  3 
Estimated # of Rows Returned:  1 
Temporary Files Required For: Order By  

   1 ) denn.h: INDEX PATH

        Filters: (denn.h.publ =  2  AND denn.h.pos >=  6543  ) 

    ( 1 ) Index Keys: trdate id boardgroup numtrades   (Key-First)  (Serial, fragments: ALL)
        Lower Index Filter: (denn.h.trdate =  13 - 07 - 2005  AND denn.h.id = ANY <subquery> ) 
        Key-First Filters:  (denn.h.numtrades >  0  )

   2 ) denn.s: INDEX PATH

    ( 1 ) Index Keys: idsector id   (Serial, fragments: ALL)
        Lower Index Filter: (denn.h.id = denn.s.id AND denn.s.idsector = 'securies' ) 
NESTED LOOP JOIN

    Subquery:
    ---------
    Estimated Cost:  3 
    Estimated # of Rows Returned:  12 

       1 ) informix.secsli: INDEX PATH

            Filters: informix.secsli.sec_publ =  1  

        ( 1 ) Index Keys: idsector idseclist   (Serial, fragments: ALL)
            Lower Index Filter: (informix.secsli.idseclist = 'INDEXSECS' AND informix.secsli.idsector = 'securies' ) 



QUERY:
------
SELECT FIRST  20  h.pos, h.id,
h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d'), h.*
    FROM ngcb_hist h, secs s
    WHERE h.id IN
    (SELECT id FROM secsLI WHERE idSecList='INDEXSECS'
      AND idSector='securies' AND sec_publ= 1 )
    AND h.pos>= 6543 
    AND h.publ= 2 
    AND h.id=s.id
    AND h.trdate=mdy( 7 , 13 , 2005 )
    AND h.numtrades> 0 
    AND s.idSector='securies'
    ORDER BY  1 

Estimated Cost:  3 
Estimated # of Rows Returned:  1 
Temporary Files Required For: Order By  

   1 ) denn.h: INDEX PATH

        Filters: (denn.h.publ =  2  AND denn.h.pos >=  6543  ) 

    ( 1 ) Index Keys: trdate id boardgroup numtrades   (Key-First)  (Serial, fragments: ALL)
        Lower Index Filter: (denn.h.trdate =  13 - 07 - 2005  AND denn.h.id = ANY <subquery> ) 
        Key-First Filters:  (denn.h.numtrades >  0  )

   2 ) denn.s: INDEX PATH

    ( 1 ) Index Keys: idsector id   (Serial, fragments: ALL)
        Lower Index Filter: (denn.h.id = denn.s.id AND denn.s.idsector = 'securies' ) 
NESTED LOOP JOIN

    Subquery:
    ---------
    Estimated Cost:  3 
    Estimated # of Rows Returned:  12 

       1 ) informix.secsli: INDEX PATH

            Filters: informix.secsli.sec_publ =  1  

        ( 1 ) Index Keys: idsector idseclist   (Serial, fragments: ALL)
            Lower Index Filter: (informix.secsli.idseclist = 'INDEXSECS' AND informix.secsli.idsector = 'securies' )

Разницы в планах выполнения я не заметил. И забил на директивы оптимизатора...
...
Рейтинг: 0 / 0
30.11.2005, 13:58
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408514
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Журавлев Денис
Бд на мой вкус криво спроектирована:
FROM secs s WHERE s.idSector='securies'
FROM secsLI WHERE idSector='securies'
FROM boardSelect WHERE idSector='securies'
Ага - особенно если idSector [N]VARCHAR :)
Смотри прочие thread'ы про индексы :))
...
Рейтинг: 0 / 0
30.11.2005, 14:02
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408523
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубый
Разницы в планах выполнения я не заметил. И забил на директивы оптимизатора...
А сколько времени запрос выполняется? А без order by сколько?
На самом деле first_rows хороший хинт, и информикс не будет сортировать, а пойдет по индексу, даже если джойнится много таблиц. Это даже не хинт, это доп.информация оптимизатору, что нам нужны первые строки, ведь у вас first 20
...
Рейтинг: 0 / 0
30.11.2005, 14:04
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408538
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
АнатоЛой Журавлев Денис
Бд на мой вкус криво спроектирована:
FROM secs s WHERE s.idSector='securies'
FROM secsLI WHERE idSector='securies'
FROM boardSelect WHERE idSector='securies'
Ага - особенно если idSector [N]VARCHAR :)
Смотри прочие thread'ы про индексы :))
Индекс тут как раз используется, проблемы с VARCHAR остались в прошлом, в 7-ке.
...
Рейтинг: 0 / 0
30.11.2005, 14:07
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408566
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Денис, не могли бы вы определить понятие селективности? А то никто мне внятно не может обьяснить. Спасибо заранее :)

Журавлев ДенисСудя по Filters: (denn.h.publ = 2 AND denn.h.pos >= 6543 ) более эффективным был бы trdate, pos.


Эффективность индекса как раз и определяется этой селективностью, как я понял. Если первый ключ может существенно сузить облать поиска, то выбирается именно он. trdate - это дата, данные хранятся за несколько лет, за один день порядка 400 записей. Роs - уникальна для каждой строки (не спрашивайте почему) Насколько селективен индекс по trdate?

Журавлев ДенисВидимо информикс думает что SELECT id FROM secsLI вернет много строк, кстати у меня есть подозрение в этом случае лучше не IN, а EXSIST, и вообще переделать подзапрос в джойн, если он возвращает более одной строки.


Джойн мне немного сложнее формировать... Впрочем, где-то прочитал что подселекты оптимизатор все равно раскладывает в джойн.

Журавлев Денис
Возможно надо несколько индексов, надо цель оптимизации сначала определить, а потом ставить задачи.


Цель оптимизации - скорострельность. Параметр - чем больше тем лучше. Текущий уровень, в принципе, удовлетворяет, но потолок уже близок...

Другая цель оптимизации - научится оптимизации :)

Журавлев Денис
Оптимальных индексов не бывает, нужен критерий оптимальности.
Самое важное это правильный порядок соединения таблиц, индексы на втором месте.

Про порядок колонок: индекс может использоваться если его первые поля были в запросе.
в запросе where trdate =?
может использоваться индекс (trdate, id)
а (id, trdate) не может
но (id, trdate) может использоваться при where trdate = ? and id =?
Если id внешний ключ, то возможно нужен индекс где оно первое.
Если h.numtrades>0 редко (отсекаем выходные?), то его можно не включать в индексы.
Если во многих запросах есть h.pos>=? AND h.publ=? AND h.trdate=?, то возможно нужен trdate, publ, pos, но все зависит от селективности. Например если publ всегда =2, то в индекс его можно не включать. Но если селективность высокая или есть исключения, то его можно включить.

Бд на мой вкус криво спроектирована:
FROM secs s WHERE s.idSector='securies'
FROM secsLI WHERE idSector='securies'
FROM boardSelect WHERE idSector='securies'


h.numtrades>0 у 2/3 записей
publ=2 практически всегда (99,9% строк)

Вкусы на структуру БД у всех разные ;)

Насчет порядка соединения - а как бы его проанализировать? Есть 3 таблицы, одна так сказать ведущая, 2 - вспомогательные; вспомогательные вяжутся в главной одним полем; на все таблички наклыдываются разнообразные условия.

И еще раз - что же такое селективность?... (где же у него кнопка? (ц) Урри :)
...
Рейтинг: 0 / 0
30.11.2005, 14:16
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408579
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Журавлев ДенисИндекс тут как раз используется, проблемы с VARCHAR остались в прошлом, в 7-ке.
ОК, уболтали :)
В ближайшее время возвращаюсь из прошлого...
...
Рейтинг: 0 / 0
30.11.2005, 14:21
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408584
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Журавлев Денис Сугубый
Разницы в планах выполнения я не заметил. И забил на директивы оптимизатора...
А сколько времени запрос выполняется? А без order by сколько?
На самом деле first_rows хороший хинт, и информикс не будет сортировать, а пойдет по индексу, даже если джойнится много таблиц. Это даже не хинт, это доп.информация оптимизатору, что нам нужны первые строки, ведь у вас first 20

времена не тестировал :( каюсь. Слишком много запросов, надо было бить по площадям. Сейчас - можно и потестировать (кста, как в dbaccess выводить время выпалнения - есть така фича?)

А оптимизатор сам что ли не видит, что у него в запросе first 20? %)
...
Рейтинг: 0 / 0
30.11.2005, 14:23
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408608
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
СугубыйДенис, не могли бы вы определить понятие селективности? А то никто мне внятно не может обьяснить. Спасибо заранее :)Ох, тяжело это. Давай, не будем говорить большая и маленькая селективность, а то совсем запутаемся, будем говорить хорошая селективность.

Поле F содержит много разных значений 0,1,2,3,2,1,4 выполняется много запросов where F=? - селективность поля хорошая.

Поле F содержит мало разных значений 0,0,0,0,0,0,1,1,1,1 селективность поля плохая.

Поле F содержит мало разных значений 0,0,0,0,0,0,0,4 выполняется много запросов where F=0 - селективность поля плохая, а для where F=4 - селективность поля хорошая.



СугубыйНасчет порядка соединения - а как бы его проанализировать? Есть 3 таблицы, одна так сказать ведущая, 2 - вспомогательные; вспомогательные вяжутся в главной одним полем; на все таблички наклыдываются разнообразные условия.
Читаем план:
Код: plaintext
1.
2.
3.
  1) denn.h: INDEX PATH
  2) denn.s: INDEX PATH
NESTED LOOP JOIN
Идем в табличку 1 берем запись, идем в табличку 2, находим все соотвествующие h.id=s.id, идем в табличку 1.
...
Рейтинг: 0 / 0
30.11.2005, 14:32
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408633
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубый
выбирается именно он. trdate - это дата, данные хранятся за несколько лет, за один день порядка 400 записей. Роs - уникальна для каждой строки (не спрашивайте почему) Насколько селективен индекс по trdate?
Индекс по trdate эффективен, по Роs намного эффективнее при условии что Роs используется в where.

Сугубый
Цель оптимизации - скорострельность. Параметр - чем больше тем лучше. Текущий уровень, в принципе, удовлетворяет, но потолок уже близок...
Другая цель оптимизации - научится оптимизации :)
Я понял сейчас. Вы этим запросом листаете 1000 строк кусочками по 20 строк с помощью Роs >, вам однозначно надо уйти от сортировки.


Сугубыйh.numtrades>0 у 2/3 записей
Плохая селективность. Индекс не нужен.
Сугубый
publ=2 практически всегда (99,9% строк)Очень плохая селективность. Индекс не нужен.
...
Рейтинг: 0 / 0
30.11.2005, 14:42
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408644
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубыйвремена не тестировал :( каюсь. Слишком много запросов, надо было бить по площадям.Как можно оптимизировать "скорострельность" без времени?

Сугубый Сейчас - можно и потестировать (кста, как в dbaccess выводить время выпалнения - есть така фича?)Не знаю как dbaccess :(. Чаще пользуюсь eSQLEditor , там вроде есть такая фича.
Сугубый
А оптимизатор сам что ли не видит, что у него в запросе first 20? %)По моему не видит, 100% гарантии дать не могу.
...
Рейтинг: 0 / 0
30.11.2005, 14:47
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408873
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Журавлев ДенисИндекс по trdate эффективен, по Роs намного эффективнее при условии что Роs используется в where.


сначала я создавал такие составные индексы, в которых pos был на первом месте. оптимизатор их _не_использовал_ , наверно потому что у меня стоит pos > NNN и индекс по этому полю отсекает половину таблицы. А это мало. Оптимизатору лучше сразу выкусить из всех значений наименьший кусок. И он ставил на первые места trdate (дату, одну из нескольких лет)

Журавлев Денис
Я понял сейчас. Вы этим запросом листаете 1000 строк кусочками по 20 строк с помощью Роs >, вам однозначно надо уйти от сортировки.


Вот здесь поподробнее, плз. Я знаю, что индекс используется при сортировке, если только все выбираемые поля лежат в индексе. У меня же в ngcb_hist 30 полей. Все их в индекс? нереально.


Журавлев Денис
Сугубыйh.numtrades>0 у 2/3 записей
Плохая селективность. Индекс не нужен.
Сугубый
publ=2 практически всегда (99,9% строк)Очень плохая селективность. Индекс не нужен.

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

Журавлев ДенисКак можно оптимизировать "скорострельность" без времени?

на глазок :) по времени отклика браузера :)

Журавлев Денис
Не знаю как dbaccess :(. Чаще пользуюсь eSQLEditor , там вроде есть такая фича.


пасиб, посмотрим.
...
Рейтинг: 0 / 0
30.11.2005, 15:39
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408947
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубый
Журавлев Денис
Я понял сейчас. Вы этим запросом листаете 1000 строк кусочками по 20 строк с помощью Роs >, вам однозначно надо уйти от сортировки.


Вот здесь поподробнее, плз. Я знаю, что индекс используется при сортировке, если только все выбираемые поля лежат в индексе. У меня же в ngcb_hist 30 полей. Все их в индекс? нереально.
Вы путаете, в индексе должны быть поля по которым сортируется.

Сделай индекс (trdate, pos), собери статистику, и покажите план:
Код: plaintext
1.
2.
3.
4.
5.
 SELECT /*+first_rows*/ FIRST  20  h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d')
    FROM ngcb_hist h
    AND h.pos>= 6543 
    AND h.publ= 2 
    AND h.trdate=mdy( 7 , 13 , 2005 )
    ORDER BY  1

А зачем надо 30 полей сразу?
...
Рейтинг: 0 / 0
30.11.2005, 15:58
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408948
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Журавлев Денис
Сугубый Сейчас - можно и потестировать (кста, как в dbaccess выводить время выпалнения - есть така фича?)Не знаю как dbaccess :(. Чаще пользуюсь eSQLEditor , там вроде есть такая фича.
Сугубый
А оптимизатор сам что ли не видит, что у него в запросе first 20? %)По моему не видит, 100% гарантии дать не могу.

А прикольная у вас программка :) Пасиба, буду юзать.

Скорость выполнения с {+First} и без него одинаковы (в пределах точности) - 250 и 280 миллисек, к примеру. Видать оптимизатор сам видит, что у него FIRST 20 в запросе стоит :)
...
Рейтинг: 0 / 0
30.11.2005, 15:59
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408964
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
СугубыйСкорость выполнения с {+First} и без него одинаковы (в пределах точности) - 250 и 280 миллисек, к примеру. Видать оптимизатор сам видит, что у него FIRST 20 в запросе стоит :)Это ничего не доказывает. Я не поверю, пока не увижу что из-за FIRST 20 меняется план.
...
Рейтинг: 0 / 0
30.11.2005, 16:02
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408984
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
ой, ошибся, с /*+first_rows*/ - то же саме.
...
Рейтинг: 0 / 0
30.11.2005, 16:08
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33408998
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Сугубыйой, ошибся, с /*+first_rows*/ - то же саме.Да я догадался.


Просто смотрим первую строку плана при first_rows и видим:
Код: plaintext
QUERY:        (FIRST_ROWS OPTIMIZATION)

А без хинта, один first 20:
Код: plaintext
QUERY:
Хотя это все фигня конечно.
...
Рейтинг: 0 / 0
30.11.2005, 16:12
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33409022
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
Журавлев ДенисВы путаете, в индексе должны быть поля по которым сортируется.

Сделай индекс (trdate, pos), собери статистику, и покажите план:
Код: plaintext
1.
2.
3.
4.
5.
 SELECT /*+first_rows*/ FIRST  20  h.pos, h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d')
    FROM ngcb_hist h
    AND h.pos>= 6543 
    AND h.publ= 2 
    AND h.trdate=mdy( 7 , 13 , 2005 )
    ORDER BY  1


Сделал и вот что получилось:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
QUERY:        (FIRST_ROWS OPTIMIZATION)

------
SELECT /*+first_rows*/ FIRST  20  h.pos,
 h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d')
    FROM ngcb_hist h
    WHERE h.pos>= 6543 
    AND h.publ= 2 
    AND h.trdate=mdy( 7 , 13 , 2005 )
    ORDER BY  1 

DIRECTIVES FOLLOWED:
FIRST_ROWS
DIRECTIVES NOT FOLLOWED:

Estimated Cost:  132 
Estimated # of Rows Returned:  252 
Temporary Files Required For: Order By

   1 ) denn.h: INDEX PATH

        Filters: (denn.h.publ =  2  AND denn.h.pos >=  6543  )

    ( 1 ) Index Keys: trdate boardgroup id numtrades   (Serial, fragments: ALL)
        Lower Index Filter: denn.h.trdate =  13 - 07 - 2005

он его не использует вообще. Ему больше нравится (trdate boardgroup id numtrades)

счас делаю update statistics HIGH для ngcb_hist - может что поменяется

Журавлев Денис
А зачем надо 30 полей сразу?

ну вот к примеру http://www.micex.ru/online/stock/archive/by_date.html?ssector=securies&doSearch=auto
...
Рейтинг: 0 / 0
30.11.2005, 16:18
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33409074
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Попробуй:

SELECT /*+first_rows*/ FIRST 20 h.trdate, h.pos, ....
...
ORDER BY 1, 2

Сугубый
счас делаю update statistics HIGH для ngcb_hist - может что поменяется
HIGH необязательно, в случае добавления нового индекса.
...
Рейтинг: 0 / 0
30.11.2005, 16:32
| Ответить | Цитировать | Написать  
Создание оптимальных индексов
    #33409090
Сугубый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сугубый
Гость
упс, накладочка, перепутал сервера где выполнялись запросы :(

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
QUERY:        (FIRST_ROWS OPTIMIZATION)

------
SELECT /*+first_rows*/ FIRST  20  h.pos,
 h.id, h.idBoard, TO_CHAR(h.trdate, '%Y-%m-%d')
    FROM ngcb_hist h
    WHERE h.pos>= 6543 
    AND h.publ= 2 
    AND h.trdate=mdy( 7 , 13 , 2005 )
    ORDER BY  1 

DIRECTIVES FOLLOWED:
FIRST_ROWS
DIRECTIVES NOT FOLLOWED:

Estimated Cost:  55 
Estimated # of Rows Returned:  243 

   1 ) denn.h: INDEX PATH

        Filters: denn.h.publ =  2 

    ( 1 ) Index Keys: trdate pos   (Serial, fragments: ALL)
        Lower Index Filter: (denn.h.trdate =  13 - 07 - 2005  AND denn.h.pos >=  6543  )

индекс испорльзуется и пропала строчка
Temporary Files Required For: Order By - значит сортировка идет по индексу?

Интересно
...
Рейтинг: 0 / 0
30.11.2005, 16:38
| Ответить | Цитировать | Написать  
25 сообщений из 46, страница 1 из 2
  1  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Создание оптимальных индексов
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=44&msg=33408948&tid=1608822]:
 0ms
get settings:
 7ms
get forum list:
 16ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 21ms
get topic data:
 8ms
get forum data:
 3ms
get page messages:
 65ms
get tp. blocked users:
 1ms
others: 203ms
total:  330ms
созд. / загр.: 330ms
x
x
Закрыть


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