|
|
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Всех приветствую. Существует следующая проблема: Сервер: Sybase ASA 9.0.2.3402 Таблица: Код: plaintext 1. 2. 3. 4. 5. 6. Таблица ~2.5 млн. записей. Создаем индекс: Код: plaintext Пишем запрос (отбираем количество записей за 2 дня): Код: plaintext 1. 2. Execution time: 0.047 seconds Через графический GET PLAN показывает что Index Scan (aaa) Пишем запрос (отбираем количество записей за 4 дня): Код: plaintext 1. 2. Execution time: 13.266 seconds Через графический GET PLAN показывает что Table Scan. Кто скажет в чем проблема? Почему при поиске двух дней использует индекс, а при четырех днях делает уже поиск по всей милионной таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 10:00 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
pit_birn, Вот читайте и наслаждайтесь: И еще один глюк в АСА, теперь и в 9.02.3044 Только внимательно, особенно про convert... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 10:29 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Так какой выход? Создавать фиктивное поле куда переводить дату в целочисленное число и по нему делать поиск? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 11:51 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
pit_birn wrote: > Кто скажет в чем проблема? > Почему при поиске двух дней использует индекс, а при четырех днях делает > уже поиск по всей милионной таблице? Так ты познакомился с COST-based оптимизатором ... И его глюками. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 12:06 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
pit_birn, Это вторая проблема, которая может встретится. Ваша, судя по этому , может решится несколькими способами: 1) перестройкой статистики 2) в явном виде указать серверу в условии convert(date,'тут нужная дата') вместо 'тут нужная дата' 3) в явном виде говорить серверу брать индекс: force index() 4) если, не поможет, есть путь уходить от даты в таких таблицах. Там действительно существуют какие-то скрытые гири, связанные с работой индексов. После того, я везде стал использовать поля smallint|integer. Все работает железно и предсказуемо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 12:15 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
1. Код: plaintext Код: plaintext 1. 2. Код: plaintext 1. 3. Код: plaintext 1. Не помогло. Или опять что-то не так делаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 12:35 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
без планов выполнения запросов что-то сложно сказать. Попробуйте еще и такой вариант: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 14:53 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Надо бы не на время выполнения глядеть, а на план. И второе, неочевидный синтаксис, вроде как with(index(...)) должно быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 14:54 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Как выводить текстовый план запроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 15:18 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. ( Plan [ Total Cost Estimate: 49.151023 ] ( SingleRowGroupBy ( TableScan Opers1[ ( 20100301 <= Opers1.DteIndex < 20100401 ) : 19.35133284% Statistics ] ) )) Код: plaintext 1. 2. 3. 4. 5. 6. ( Plan [ Total Cost Estimate: 1831.714457 ] ( SingleRowGroupBy ( IndexScan Opers1 dteindex1 ) )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 15:32 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Что же ASA даже целочисленные индексы чтоли не умеет брать? Или может какие-то настройки сервера есть по размеру кэша у индекса или еще что-то подобное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 15:32 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
07.04.2010 16:32, pit_birn пишет: > Что же ASA даже целочисленные индексы чтоли не умеет брать? Не считай сервер глупее себя. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 15:39 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Какие планы получаться если выполнить Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 15:49 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
У меня поле dteindex - теперь целочисленное. Запустил без кавычек. Код: plaintext 1. 2. 3. 4. 1ый: ( Plan [ Total Cost Estimate: .000001 ] ( SingleRowGroupBy ( PreFilter [ FALSE ] ( TableScan Opers1 ) ) )) 2ой: ( Plan [ Total Cost Estimate: .0900045902 ] ( SingleRowGroupBy ( IndexScan Opers1 dteindex1 ) )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:07 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
ну теперь все ясно: там где нет хинта сервер оценил, что в запрос попадет 19.35133284% всех данных. 20% от таблицы это однозначно выбор за table scan. Если 20% - это правда и сервер неошибся при оценивании статистики, то план правильный. Если нет, то надо обновить статистику и повторить запрос. Обратите внимание на оценку стоимости зпросов с индексом: 1831.714457 и без индекса: 49.151023 Ежу ясно, что сканирование дешевле. В общем все упирается в статистику, верна она или нет. Можно даже без перестройки статистики проверить запросом: Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:09 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. @a1=224149 @a2=1158308 probability=19 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:15 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Т.е. в подобных ситуациях нужно "насильно" указывать в запросах использование индекса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:20 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
2pit_birn что и требовалось доказать. статистика верна и сервер в общем правильно выбрал план. Осталось выяснить так ли это на самом деле. - Какое время выполнения запроса с хинтом на индекс и без него? Если не хочется хинтовать то можно поиграться с такими параметрами: Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:28 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
а для общего развития стоит покурить весь раздел в документации: Query Optimization and Execution ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:31 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. ( Plan [ Total Cost Estimate: 41.63739025 ] ( SingleRowGroupBy ( TableScan Opers1[ ( 20100101 <= Opers1.DteIndex < 20100105 ) : 2.258879392% Index ] ) )) Тогда вот эта ситуация не ясна. Почему при 2.25% он использует TableScan? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:38 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
А вы зачем статистику дропнули? Как работает оптимизатор при полностью отсутсвующей статистике я точно не знаю. Помню, что в sybase asa 5.5 оптимизатор был не cost-based а rule-based. Это означало, что статистику сервер оценивал не исходя из реальноuj распределения данных, а исходя из применямых операций сравнения в where. Если стояло =, то считалсь, что захватывается малый процент строк и надо было стремиться взять индекс. А если были фильтры по <,> то считалось, что захватывается большой процент строк и надо сканирование. Так что вы статистику верните обратно и повторите запрос на действительно маленьком интервале дат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:48 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Выдержка из документации: The DROP STATISTICS statement deletes all internal statistical data from the ISYSCOLSTAT system table for the specified columns. This drastic step leaves the optimizer with no access to essential statistical information. Without these statistics, the optimizer can generate very inefficient data access plans , causing poor database performance. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 16:50 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. Код: plaintext 1. 2. 3. 1ый: ( Plan [ Total Cost Estimate: 60.68097175 ] ( SingleRowGroupBy ( IndexScan Opers1 dteindex1 ) )) 2ой:( Plan [ Total Cost Estimate: 105.9351135 ] ( SingleRowGroupBy ( TableScan Opers1[ ( 20100101 <= Opers1.DteIndex < 20100115 ) : 8.063234049% Statistics ] ) )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 17:10 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Ну а время выполнения какое с индексом и без него? Если без индекса быстрее, то чего париться то? В последнем запросе у вас попадает в выборку 8% данных, что не мало и скан вполне рабочее решение. Сложность оптимиатора состоит не в том, что-бы индекс вставить, а что-бы затратить минимум ресурсов на выполнение запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 18:13 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 18:21 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=36566593&tid=2010686]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
172ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 280ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...