В таблице есть 2 индекса (вообще то больше, но там все ясно)
create index ext_id on trans (ext, id) и create index id on trans (id)

В их необходимости сомнений нет, в смысле поиски идут по обоим, сомнение в "довеске" id в первом. Т.е. насколько этот "довесок" используется информиксом?
Не проще ли обойтись простыми
create index ext on trans (ext) и create index id on trans (id)

Запросы используют насколько могу судить все варианты в примерно одинаковой мере...
т.е. "WHERE ext = ... AND id = ..." (примерно в 30% случаев) и "WHERE ext = ..." (примерно в 30% случаев) и "WHERE id = ..." (примерно в 30% случаев, хотя тут чаще не "чистое условие", а в паре с временем например, "чистое" по количеству возвращенного не пройдет)

Причем:
поле ext строка "с претензией на уникальность" т.е. там и гуиды в строках, и свои от времени например рассчитанные значения... но все таки не уникальные (а каких то значений может быть много).
поле id имеет всего примерно 1500 (int-овых) значений, что на 50-ти миллионную таблицу не так уж много для индекса.

Ну, вот, в MSSQL я бы сделал 2 простых... он прекрасно работает и при "спаривании" в условии разных индексов. А в информиксе? Мне говорят "это для быстродействия" (тех самых первых 30% запросов), и типа когда он был не составным, а обычным (как считаю правильнее), все "очень тормозило"... НО!!! Меня не покидают смутные сомнения, что проблема в чем то другом.
Очень уж похоже на -
p.s. "Ноги" некоторым образом "растут" отсюда , если кому интересно.
но тут без возможности даже проверить.

Как мне кажется (откуда вообще сомнения) при выборке небольшого количества записей по первому индексу, на второй SQL даже не будет внимания обращать (ну к примеру 10 записей проще в памяти просканировать).
Т.е. тормозов быть не должно.
А раз были то причиной могло быть то, что информикс считал числовой индекс (id) более "легким" и делал его главным...

Что решили добавив id к первому индексу (использовать один для проверки 2х значений еще "легче", и все исправилось). Но, главную проблему это не решило, и они как-то связаны эта и "моя" из предыдущего топика.

p.s. Просто подозреваю, что проблема базы тут не первый год... (добавили id в индекс года три назад, а вообще база работает около 10)

АнатоЛойTesla13,

Чем в случае с ногами то закончилось?Фактически ничем, это продолжение. Сейчас пытаются оптимизировать структуру, размер (поля лишние убрать)... думают что это из-за размера таблицы.
В данный момент все работает, или вернее не работает также как было (и кстати хинт от DrGonzo помог только на определенных данных... я потом с другими данными и на запросе с хинтом тормоза "ловил". как временное решение убрали DESC из запросов... немного не то, с начала, а не с конца, но 80% нужд перекрывает, не у всех больше 100 нужных записей, а если больше то можно период дополнительно задавать... ну и 100 на 500 увеличили)

АнатоЛойРечь об одной и той же таблице вобеих топиках?Да.
И таблица и запросы и индексы и типы, все реально "as is", и те же самые по соответствиям, единственное, что позволил себе так это имена подсократить... (но соответственно без одного имени на разные поля... просто не думаю, что было бы понятнее если бы вместо ext/id я приводил бы extid_user_by_trans_codе и user_by_trans_codе_id а писать упаришься, да еще опечаток наделаешь)

АнатоЛойTesla13,
1. у вас в первом топике до сих пор не видно, решилась ли проблема с дубликатами в поле, которое является первичным ключом... Может он отлючён?

2. У вас доступ к БД sysmaster есть?Дубли удалили. Вряд ли отключен, если бы так то выборка по нему делалась бы сканированием, а это на 50 мл. таблице дело долгое, не 0,016 мсек. точно. Но может временами и отключают (ну на тех. работы к примеру, не знаю. я на фоксе например индексы отключал для массовых вставок, а после пере-индексировал, быстрее вставки на подключенных работало. может тут что-то похожее делают. откуда то же дубли взялись).
Доступа нет. ;(

АнатоЛойВам хочется порассуждать на теоретическую тему или решить практическую проблему?Мне бы экспертную оценку... а решить я ничего не могу, даже если бы знал как и из-за чего.

АнатоЛойВ чём главная проблема то?Денег не хватает... хотя, если подумать и это не главная. :))

Если серьезно, то я с этими проблемами не могу сделать как надо то, что нужно. И объяснить начальству "в чем проблема" тоже не могу. Аргументированно не могу. А у бд. админов проблем нет, им пофигу. Работает же как то.
Не знаю уж в чем тут главная проблема... наверное в том, что мне не пофигу. Но это вообще то оффтопик.

АнатоЛойНе вижу смысла в эффективности и практической полезности вашей деятельности вообще: админского доступа к БД нет, но решать проблемы, тесно связанные с правами админа пытаетесь...Тут ко всему прочему еще и привычка. :) Долгое время проработал админом MSSQL-я. Хотя, за то время я "напрограммировал" примерно столько же сколько при работе программистом.

p.s. Еще один оффтопик. :) Лучше не спрашивайте.

Журавлев Дениси еще есть параметр DS_NONPDQ_QUERY_MEM, позволяющий сортировки вынести в памятьБоюсь памяти не хватит. (можно посчитать сколько она примерно "весит", но завтра)

Журавлев Денися кстати тоже не понял в чем проблема.Я пишу программу, программа использует базу (зависит от нее), заказчик (руководство) не понимает почему не сделано так как они хотят. Мне нужно либо объяснить, и сказать, что для этого нужно (админ либо не способен либо не хочет), либо уволится. (хотя надеюсь до этого не дойдет)
Так понятнее?

АнатоЛой5. Вы сомневаетесь, что причиной улучшения ситуации стал отнюдь не новый индекс.Типа того. Или если помогло все таки изменение индекса, то сомневаюсь, что с базой было все в порядке еще тогда "до меня"... ну не верю, что будет ощутимый прирост скорости от такого изменения при нормальной работе, а вот если оптимизатор/статистика неверно определяет "вес" и что использовать первым, то вполне.

Аргумент админа "тебя не было и все работало, ни у кого претензий не было, а тут раз и все плохо...". А вот эта не логичность показывает что не все было так хорошо как он говорит.
Со своей стороны вижу кучу нелогичности в работе базы. Это не первая и не вторая. Но о всех, тем более о которых знаю еще меньше чем про это не охота писать.

АнатоЛой2. более-менее уверенно проверить можно практически:О... если бы кто то чего то делал вот так, практически, я бы второй раз сюда не писал.
А пока все похоже на шаманские действия, типа "а че вы хотите? таблица большая... ну давайте ненужные поля уберем, вот структура, и что убираем, кому нибудь нужно убираемое?". (и тут обращаю внимание на дублирующийся индекс, он что места не занимает, зачем нужен?)

АнатоЛойА рассуждать теоретически довольно накладно - слишком много предположений...Это да, но ИМХО, все вполне конкретно. Ответ на вопрос, конкретизирую - "будет ли ощутимый выигрыш по времени (с около минуты как говорят старожилы) до пары секунд как сейчас, от составного индекса взамен пары"?
В MSSQL я бы сказал, что это невозможно. А с информиксом может это нормально? Я же не знаю, вот в той теме уже предположил неадекватность информикса, а оказалось что скорее админа, т.что...

Журавлев Денисчто вам мешает сделать как они хотят? При чем тут вообще информикс?Прочитай эту тему.
Или кратко - время исполнения запроса варьируется от 15мсек до бесконечности... в зависимости от, какие значения/критерии поиска задать в программе.
И мне как то неоткуда взять инфу заранее и предупредить юзера "Внимание! Поиск Агента с кодом 7 'повиснет'! Не хотите вместо него поискать Агента с кодом 127?".

Причем информикс? Проблемы с ним, или вернее с базой/настройкой/индексами.

АнатоЛойTesla13Будет ли ощутимый выигрыш по времени (с около минуты как говорят старожилы) до пары секунд как сейчас,
от составного индекса взамен пары.

Очуметь, Tesla13, нельзя ли изъясняться поконкретней.
Т.е. ситуация такая. Вы хотите понять, что лучше из пары индексов
а) (ext, id) и (id)
или
б) (ext) и (id)
при описанных вами условиях в первых постах?Да. Это мне поможет.
И желательно насколько лучше (т.к. прирост от индекса ext, id при поисках по обоим очевидно будет... теоретически, т.к. по моему опыту с MSSQL он практически незаметен).
Т.е. если тут резерв ускорения на "на порядок", в условиях нормальной работы базы (что я проверить никак не могу, за неимением таковой).

IkirИ это логично. Представьте, что из 50 000 000 записей у вас: 40 000 000 записей Агента с кодом 7 и 100 записей с Агентом 127.Это не логично. Представьте, что в запросе всегда (!), стоит FIRST 100, больше не надо, и плевать совершенно 200 записей там или миллионы... во всяком случае в MSSQL. Выборка по индексу, какая разница сколько записей в базе, если это не фулл скан.

Журавлев Денисплан запроса стабилизируй хинтами.Пытался (в прошлой ветке подсказали), как оказалось тоже не работает, вернее, работает под один вариант условий/данных, под другой нет.

АнатоЛойЕсли уже есть индекс по (ext, id) зафиксируй, как писал Денис выше, какой индекс использовать.Блин, да нафига? Тема поднята не для "КЭП-ов", чтобы им покуражится, а выяснить, не было создание этого самого индекса "первой ласточкой" проблем базы.

victor16Интересная тема обсуждалась ранее Explain при отсутствии физического доступа к серверу - как? Никак. Если бы у меня была рабочая папка на сервере, юзерская как там написано... но я как бы с того и начал, что ничего нет, кроме DNS, а он работает по имя сервера + порт.

p.s. Ну да ладно, все с вами ясно.