|
|
|
Индекс на дату (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 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Да я же говорю, что известная фигня. На больших объемах он тупит. И также не нужно считать оптимизатор "умнее" себя. Он не умнее и не глупее, он алгоритм. И где-то в его логике косяк. А косяк заключается в том, что план он выбирает исходя из cost оценки. Вот только проблема в том, что оценка не совпадает с действительностью. На больших относительно кэша таблицах далеко не совпадает. Он считает, что без индекса быстрее, а по факту получается не так. И каждый раз не так. Я уже давно наигрался на своих мега-табличках и помогает только force index. Судя по всему у оценщика нехватает разрядности во внтуренних алгоритмах или еще чего-то. Ведь граница в 20% - это подходит не ко всем таблицам. А если таблица 200млн? Лучше было бы, если б можно было оптимизатору явно давать информацию о стоимости IO диска и памяти. И чтобы он учитывал это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 19:52 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Вот с этой опцией optimization_goal очень опасно играться. Может выйти боком совершенно в другом месте. Причем может произойти через год, и будете ломать голову с другими запросами почему вдруг перестало работать. Я такие грабли уже имел в 2005-м. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 21:04 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Вообще аса учитывает стоимости работы IO конкретной базы, но по умолчанию там заданы усредненные параметры. Для того, что-бы сервак знал и учитывал производительность конкретного железа в доке рекомендуют сделать один раз CALIBRATE DATABASE Во всяком случае, это команда не навредит. Я лично с такими траблами не сталкивался, проверить не на чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2010, 22:12 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Ggg_old, А что это за CALIBRATE DATABASE такое? Не могу в реферансе найти... Может оно тут как раз поможет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2010, 09:53 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Извиняюсь, эта опция точно находится здесь: ALTER DATABASE { CALIBRATE [ SERVER ] | CALIBRATE DBSPACE dbspace-name | CALIBRATE DBSPACE TEMPORARY | CALIBRATE PARALLEL READ | RESTORE DEFAULT CALIBRATION } Только я взял хелп от десятки, но в девятке точно есть эта команда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2010, 10:30 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
08.04.2010 11:30, Ggg_old пишет: > Только я взял хелп от десятки, но в девятке точно есть эта команда. RTFM от 9.0.2 гласит: ALTER DATABASE { CALIBRATE [ SERVER ] | CALIBRATE DBSPACE dbspace-name | CALIBRATE DBSPACE TEMPORARY | RESTORE DEFAULT CALIBRATION } Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2010, 10:52 |
|
||
|
Индекс на дату (Sybase ASA)
|
|||
|---|---|---|---|
|
#18+
Судя по описанию, это то что нужно: You can also use ALTER DATABASE to perform recalibration of the I/O cost model used by the optimizer. This updates the Disk Transfer Time (DTT) model, which is a mathematical model of the disk I/O used by the cost model. Очень любопытно, повлияет ли и как на ситуацию у автора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2010, 11:23 |
|
||
|
|

start [/forum/topic.php?all=1&fid=55&tid=2010686]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
61ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 404ms |

| 0 / 0 |

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