Tesla13, Вам нужно знать, имеет ли смысл составной индекс.

Этот вопрос, исходя из обсуждения, можно задать в двух вариантах:

1. если запрос с "ext = x and id = y" будет выполняться с использование индекса (ext, id), насколько это будет эффективнее чем
с использованием индекса (ext)?

Не стесняясь, повторюсь: если даже теоретически прикинуть "в сколько раз будет лучше, это нужно мозги на полчаса приложить - а мотивации никакой :)" (я).

У вас в наличии сейчас и составной индекс и оба простых? Так попробуйте через хинты протестировать все три варианта, только влияние кэшрование не забудьте учесть, и будет вам счастье практическое, а не теоретическое.

2. есть три типа запроса
1) "ext = x and id = y" (30% запросов);
2)"ext = x" (30% запросов);
3) "id = y" (30% запросов).
Все запросы выполняются с условиями отбора первых 100-200 записей.
Распределение и типы данных приблизительно описаны в первых двух топиках.
Разработчик обеспечит выбранные в результате изысканий тексты запросов и администратор подберёт оптимальный сбор статистики.
Что будет эффективнее:
а) иметь наличие двух индексов: (ext, id) и (id)
или
б) иметь наличие двух индексов: (ext) и (id).
Да на таких изысканиях можно скромный курсач защитить...



Если же вернуться к проблеме.

Есть проблемы в теоретической оценке:
- разные версии Informix (а вашу точно мы тоже не знаем до сих пор) - даже минорные - имеют разные возможности по оптимизации и баги;
- мы ничего не знаем про то, как у вас собирается статистика, что немаловажно при выборе индекса оптимизатором;
- про настройки сервера;
- про переменные окружения;

Решение проблемы "с одними параметрами запрос выполняется быстро, а с другими - немеряно времени" зависит не только от наличия индекса.

Создание индекса (ext, id) админами могло улучшить ситуацию не только потому, что этот индекс лучше, а потому что оптимизатору на вход стала поступать новая информация:
0) раньше для запроса "ext = x and id = y" выбирался таки индекс по (id) , а не ext или "скрещивание (ext) и (id)". Почему: см. выше про версию информикса и статистику;
1) админы статистику заодно в процесс обновили не так как обычно;
2) ....

Местным гуру на порядок легче рассуждать: у них возможности навести резкость в постановке задачи и её окружении больше...

Tesla13, админы обычно отвечают за производительность работы БД при некотором известном/постоянном объёме запросов, разновидности этих запросов и объёме извлекаемых данных.
В какой-то момент появились вы с новыми типами запросов, новым объёмом извлекаемых данных.
Если "появление" вашей программы в качестве клиента не согласовано (какие таблицы, какие запросы, как много тянете) с админами, они даже теоретически не могут превентивно отвечать за производительность БД. Они могут только реагировать на проявившиеся проблемы в работе.

И на ваш теоретический вопрос, как должно было быть при нормальной работе админов: как угодно, если ваши запросы начали тормозить, значит они для сервера внове, и нет на практике "нормально настроенного сервера БД"...

Tesla13, не равняй MS SQL и Informix при прочих неравных (админы, БД, клиенты...).
Появление нового индекса в БД (Informix) без сопутствующих движений - вполне себе причина поломать работу системы.

Tesla13Что знаю, Informix 11
мдя. 11.10, 11.50, 11.70? не говоря уже про номер FixPack...

Tesla, давайте поступим проще, дабы не отклоняться от темы.

1) Вопрос: могли ли регулярно или нерегулярно тормозить запросы с "WHERE ext = ... и id = ..." при наличии только индексов (ext) и (id)?

Ответ: могли.

Основной вариант:
выбор оптимизатором Informix неэффективного плана запроса (индексов).

Возможные причины возникновения основного варианта:

а) обновление статистики не учитывает потребность в обработке таких запросов;
б) в запросе присутствуют дополнительные части, влияющие на выбор плана: ORDER BY, FIRST 100, перечень возвращаемых полей, которые нам не видно из постановки задачи;
в) параметры оптимизации запроса (параметры сервера, параметры сессии) "не соответствуют" типу запроса;
г) природа данных такова, что в зависимости от параметров эффективны разные индексы (то по (ext), то по (id)) но из-за кеширования запросов (и планов запросов) используется один и тот же план.

Что нужно было делать:
1. Тестировать запросы
2. "Согласовывать" с админами, раз уж админы отвечают за структуру и обслуживание БД (вау!).

2) Вопрос: могло ли пропасть торможение запросов с фильтрацией по равенству двух полей после добавления индекса (ext, id)?
Ответ: могло.
Основной вариант:
при выборе оптимизатором Informix стал использовать именно его как наиболее подходящий (более стабильный в оценках независимо от значений фильтрации) индекс.

Возможные причины возникновения основного варианта:
см. ответ на вопрос 1.

3) Вопрос:
Насколько эффективнее должно быть использование составного индекса против простых?
Встречный вопрос к постановщику: исходя из предыдущих ответов, ответ "насколько именно" всё ещё интересует?

АнатоЛойа) обновление статистики не учитывает потребность в обработке таких запросов;

читать как
АнатоЛойа) существующие процедуры обновления статистики не учитывают потребности в обработке таких запросов
(причём есть варианты, когда только изменение сбора статистики не решит проблему);

АнатоЛой1) Вопрос: могли ли регулярно или нерегулярно тормозить запросы с "WHERE ext = ... и id = ..." при наличии только индексов (ext) и (id)?

Ответ: могли.

Основной вариант:
выбор оптимизатором Informix неэффективного плана запроса (индексов).


Основные ошибки ТС:
1) предположение, что СУБД Informix работает так же, как MS SQL;
2) предположение, что СУБД Informix работает по логике, которую предполагает ТС на опыте общения с МС СКЛ, а не так, как собственно, эта СУБД спроектирована и разработана.

Tesla13, надеюсь, рассеял ваши "смутные сомнения что причина в чём-то другом"...