|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Сразу скажу что к серверу не имею отношения, только пользуюсь базой, т.е. не смогу выполнить UPDATE STATISTICS HIGH, пересоздать индексы и т.д.. И в общем не хочу, хочу понять причину... ну, а тогда решать, что делать. Что знаю, Informix 11, количество записей в интересующей таблице 44460537, полей 60, индексированы 15, нужные мне поля (по которым условие/сортировка) в том числе. Проблема в том, что выбирая небольшое количество записей (100) в паре с сортировкой (нужны последние записи) запрос "виснет"... ждал около часа, после "снял". Собственно запрос (именно так как тестил, из реального убрано все не относящееся, т.е. тут минимум который виснет) - Код: sql 1. 2. 3. 4.
Время работы > 1 час (снял) Если по отдельности Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Отрабатывает за 15-16 мсек. На оба используемых поля есть индексы (ext LIKE 'R%' тоже использует на сколько понимаю, т.к. начинается с символа), типы у ext Char(20), у tdate DBTimeStamp. Впрочем если заменить его в запросе (order by) на id типа INT PRIMARY KEY ничего не меняется. А вот если заменить ext на другое, не индексированное поле с аналогичным условием (params LIKE '9%'), или на индексированное, но с точным сравнением (parentid=0 или params='9999999999' то время запроса 15-16 мсек... Т.е. впечатление, что в нужном варианте запроса индекс поля ext только мешает. В общем, что и как можно посмотреть, чтобы точно определить? (только "извне", доступа с серверу нет) Или у кого есть возможность проверить описанную ситуацию/запрос? И кстати, пришло в голову пока писал, есть ли возможность (параметр/операнд/указание/...) отключить его использование в конкретном запросе (типа WHERE ext LIKE 'R%' NO INDEX)??? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 11:14 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
> отключить его использование в конкретном запросе Можно конечно использовать операции не использующие индексы по определению, например SUBSTR(ext, 1, 1) = 'R', проверил так работает, и быстро (те же самые 15 мсек). но это значение как раз из задаваемых, т.е. если нельзя отключить то придется писать интерпретатор вводимых значений и конвертировать в допустимые... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 11:27 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Надо хотеть собирать статистику ;-) План запроса какой? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 11:29 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Хотя нет, отключать не вариант... т.к. если введут несуществующее значение то это полный перебор, а по индексу быстро определит. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 11:32 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
klepaНадо хотеть собирать статистику ;-) План запроса какой?Как его получить, и нужны ли права? (я бесправный юзер в этой базе...) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 11:34 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 11:49 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Ну и надо понимать, что если Вы заказываете сортировку, то запрос сначала должен выбрать все значения, отсортировать и вернуть 100 строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 11:53 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
klepa http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.perf.doc/perf281.htm Не получится, как понял %INFORMIXDIR%\sqexpln\username.out. нужен доступ с серверу. klepaНу и надо понимать, что если Вы заказываете сортировку, то запрос сначала должен выбрать все значения, отсортировать и вернуть 100 строк.Я не заказываю сортировку, я указываю чтобы записи выбирались с конца таблицы (по указанному индексу). Есть разница. Сначала выбрать 100 и после их отсортировать, или выбрать 100 последних. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 12:10 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Tesla13, Надо смотреть план запроса. Возможно оптимизатор не идет по индексу из-за неправильной оценки стоимости операций. Кстати, если FIRST 100 убрать, также долго работает? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 12:51 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Ооопля, а вот это интересно... (пробую различные варианты, за не имением лучшего); В проблемном запросе, заменил поле (ext на params0) - Код: sql 1. 2. 3. 4.
И оно не повисло, отработало, и быстро... поле тоже индексированное, строковое, единственное различие тип не Char(20), а varchar(255). Нда, и это было последнее поле в списке, прямо по закону мерфи. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 13:06 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
DrGonzoВозможно оптимизатор не идет по индексу из-за неправильной оценки стоимости операций.Вряд ли, если не идет, для проверки использовать операцию гарантированно не использующую (см. выше) то как раз наоборот выборка быстрая. DrGonzoКстати, если FIRST 100 убрать, также долго работает?Конечно, но возможно уже не из-за "моей" проблемы, а из-за количества... (по условию это ~ треть от 44 миллионов) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 13:12 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
индекс trans(ext,tdate) и хинт +first_rows ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 13:56 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Журавлев Денисиндекс trans(ext,tdate) и хинт +first_rows!!! Помогло, директива {+FIRST_ROWS}. Хотя чуть дольше чем в остальных случаях, не 15 мсек, а 32 мсек (не существенно). Т.е. так - Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 14:17 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
И да. Спасибо всем, особенно Журавлеву Денису. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2012, 14:18 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Блин... опять тормоза на "ровном месте", и тут уж не знаю даже что думать... "Виснет" простейший запрос - Код: sql 1.
id - типа INT PRIMARY KEY (т.е. гарантировано индексированное), виснет если задать именно -1... Другое положительное или отрицательное (..., 2, 1, 0, -2, -3 ...)... "проблема" всплыла из-за того, что программа не найденное/неправильно введенное значение приводит именно к -1, чтобы вернуло пустой набор данных... не проблема конечно заменить на другое (-2 например), но просто как факт... что за фигня? Да, отличие от предыдущего, висит не так долго, 30 сек примерно после "отваливается" с "EOleException : Недостаточно памяти". p.s. начинаю просто таки любить MSSQL ..., раньше его адекватность воспринималась как должное. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 11:41 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Попробуйте выполнить этот запрос в другом клиенте. Например в eSQLEditor ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 12:55 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
ollegПопробуйте выполнить этот запрос в другом клиенте. Например в eSQLEditor Выдал предупреждение до выполнения (т.е. судя по этому "фича" известная, и вряд ли, что получится сделать, ну кроме смены на -2 в программе)... - "Estimated cost for then query too hight -2727904." "Too many rofs will bt returned -5661737." Если нажать продолжить то также виснет (26 сек в этот раз). Ограничение типа Код: sql 1.
ну раз слишком много возвращает, ничего не меняют. ни в таймауте ни в предупреждении. Все один в один. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 14:02 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Tesla13Ограничение типаНу вернее с правильным запросом ;). Просто пробовал в разных вариациях, а сюда не заметил скопировал "болванку", откуда составлял копипастом. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 14:05 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Все, похоже решилось... не знаю как так может быть, но у нас есть (!!!) значения с -1 в ключевом поле, причем много (а ключ он же уникальный априори...), причем если в грид (отбор по другому критерию) попадается такая запись то запрос также виснет... т.е. он что-то отбирает но только до этой записи, показывает первое поле с id = -1, и дальше ничего... запрос с асинхронным получением данных (ADO), если простой, то просто виснет. ;) А откуда eSQLEditor об этом узнал х.з... (а может не узнавал может там индекс "зациклился", а он по количеству вхождений определяет... но все одно как?) Ну да ладно, отдам админам, пусть разбираются. olleg спасибо, сам как то не подумал проверить где нибудь еще, кроме программы. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 14:48 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
eSQLEditor'у об этом сам сервер сказал - API позволяет... Tesla13id - типа INT PRIMARY KEY (т.е. гарантировано индексированное) Так "типа", или таки "PRIMARY KEY"? Или констрейнт/индекс отключён? Или повреждённый индекс? В чём проблема была-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 15:14 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
АнатоЛойТак "типа", или таки "PRIMARY KEY"? eSQLEditor говорит Код: sql 1. 2. 3. 4. 5.
АнатоЛойИли констрейнт/индекс отключён? Или повреждённый индекс? В чём проблема была-то?Почему была? Еще есть. Понятия не имею... разбираются. По логике таких значений (-1) быть не должно, вообще (почему и выбрано как представитель ошибочных значений клиента). p.s. В самом начале еще говорил, доступа к серверу у меня нет, есть только один ODBC DSN и домыслы... ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 16:53 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
АнатоЛойТак "типа", или"Типа" не типа "блатной базар", а "переменная типа" ... от слова тип. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 17:05 |
|
Тормоза запроса если есть условие и сортировка
|
|||
---|---|---|---|
#18+
Tesla13... не знаю как так может быть, но у нас есть (!!!) значения с -1 в ключевом поле, причем много (а ключ он же уникальный априори...) Я бы посоветовал админу предварительно чекнуть таблицу, а потом можно будет и порассуждать о стоимости запросов :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2012, 17:11 |
|
|
start [/forum/topic.php?fid=44&msg=38026856&tid=1607100]: |
0ms |
get settings: |
19ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
57ms |
get topic data: |
15ms |
get forum data: |
1ms |
get page messages: |
560ms |
get tp. blocked users: |
1ms |
others: | 332ms |
total: | 993ms |
0 / 0 |