alekcvp,

"плохой" индекс - индекс с плохой избирательностью (селективностью), т.е. большим количеством дубликатов ключей. Классический пример - в таблице 1000 записей, по столбцу построен индекс, в столбце 2 значения (м и ж, 1 и 2, и т.д.). Одно значение ключа - 990 записей, другое - 10. Поиск по первому значению приводит к чтению почти всех страниц с диска, т.е. к лишним операциям ввода-вывода, т.к. все равно выберется 990 записей (почти все). Поиск на второе значение - очень выгоден, т.к. выберет всего 10 записей.
Но оптимизатор не знает, поиск какого значения будет производиться, поэтому индекс в плане скорее всего будет использоваться.
Так что тут все зависит от ситуации, поиск каких значений идет по индексу, и сколько их.

Еще "качество" индекса, если он по нескольким столбцам, зависит от порядка столбцов в индексе, и их селективности.

В общем, создавать индексы вручную (кроме ПК и ФК) нужно только если они явно ускоряют производительность конкретного запроса. Бывает что разработчик наоборот, сначала нафигачит индексов на все случаи жизни, а потом удивляется почему "убирание" индекса ускоряет запрос.

Роман ЯнковскийТак пусть файрберд жрет ресурсы, чтоб его выполнить.
судя по этой фразе, вы не читали статью про железо и фб, которую я вам дал.

Роман ЯнковскийBuffers = 50000
Reads = 13818
если суперсервер, и 3.0, то можно увеличивать кэш до 200000 тысяч, только тогда надо не забыть и
FileSystemCacheThreshold
тогда увеличить, например до 300к.

база какого размера, какой размер страницы, и сколько RAM на сервере?

hvlad,

reads - это то что не влезло в кэш. Если бы оно влезало, reads было бы 0, при повторном выполнении запроса, разумеется. Но вероятно, раз приведены "с индексом и без", то скорее всего запросы можно считать повторными, и видимо, не влезает.

Роман Янковскийбаза 7.5гб (хм, подросла с тех пор, как я в последний раз смотрел, но ram можно увеличить, если это поможет)
статью читайте же. Если база 7 гиг, а памяти 16, вероятно что база уже в памяти. RAMMAP это показывает (на двух последних закладках). Понятно, что смотреть надо при интенсивной работе, а не при выполнении одного тестового запроса.

Дальше, при странице 8к и 50000 страниц кэша кэш получается 400 мегабайт. Так что его можно спокойно увеличить раза в 4, как я и предложил (если ФБ 64битный. Если 32битный, то лучше не надо).
Потом, во время работы вы можете посмотреть, сколько занимает процесс firebird.exe. Вы же не написали - сколько. Вы сообщили "использует память очень экономично".
И 7 гиг 3 раза в 16 гиг не влезет. Влезет только 2 раза. В общем, читайте статью и настраивайте. Там все есть - и рекомендации, и формулы, надо только прочитать внимательно :-)