Tesla13В таблице есть 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. "Ноги" некоторым образом "растут" отсюда , если кому интересно.
но тут без возможности даже проверить.

Всю тему не читал, но хочу вставить свои пять копеек на тему, почему индекс create index ext_id on trans (ext, id) может быть лучше / быстрее, чем create index ext on trans (ext) .

Как уже отметили, в поле ext может быть много дубликатов. Для индекса это будет означать, что на уровне листьев будет запись типа [ключ,rowid1,rowid2 ... rowidn]. При удалении или вставке, хождение по такому списку и его модификация будут более ресурсоемкими, чем если в ситуации [ключ,rowid]. Т.к. во втором случае соотв. ключ просто будет помечен, как удаленный и будет исключен из структуры индекса позже в процессе работы btree cleaner, а в первом будет foreground write.

Замена индекса на составной, с дополнительным полем сделает набор ключей в индексе более дисперсным, а следовательно количество/длину упомянутых выше списков rowid'ов меньше/короче.