В ASA на FOREIGN KEY автоматически неявно создается индекс. Так что явно индексируя поле внешнего ключа, Вы будете просто дублировать уже существующий индекс, он нигде не будет использоваться, зато будет тормозить и занимать лишнее место. В ASA 9.0 кстати внешний ключ даже можно указывать в кач-ве кластерного индекса.

Вообще в ASA как я заметил правила полезности индексации полей своеобразные и отличаются например от правил, которыми я руководствовался в MSSQL. У меня для себя как бы есть небольшой свод правил по поводу индексов, попытаюсь его озвучить:
1. Во многих общих случаях оптимизатору запросов выше крыши хватает PRIMARY KEY, FOREIGN KEY и UNIQUE CONSTRAINT (ну или UNIQUE INDEX). Строить еще какие дополнительные индексы нужно только имея веские доводы - например тормозит запрос и по плану запросов видно что ASA не может эффективно получить данные с таблицы, используя существующие индексы или же вообще производит TABLE SCAN.

2. Наличие TABLE SCAN в плане запроса не является поводом избавиться от него, пытаясь подогнать индекс. Это больше является поводом посмотреть, а какова селективность запроса. Если очень низкая (т.е. выбирается большинство записей из таблицы), то TABLE SCAN является вполне обоснованным - нет никакого смысла СУБД сначала читать весь индекс, чтобы потом все равно прочитать всю таблицу.

3. Для ASA 9.0 очень важно продумать политику кластерных индексов. При построении плана запроса кластерный индекс имеет некий приоритет, так как гарантирует упорядоченное чтение данных с таблицы. Честно говоря угадать сложно, какой индекс лучше сделать кластерным, так как впервую очередь, делая кластерный индекс стоит помнить о дефрагментации таблицы и стараться делать кластерным тот индекс, который наименее дефрагментировал бы таблицу при вставке новых записей, т.е. записи вставлялись бы по нарастающей сортировке, более менее соответствующей этому индексу. Конечно самый показательный пример такого индекса - это PRIMARY KEY на поле IDENTITY. Однако делать кластерным индексом PRIMARY KEY не панацея от бед, наоборот бывает иногда полезней сделать кластерным индексом FOREIGN KEY или UNIQUE INDEX (CONSTRAINT). Простой пример: есть 3 таблицы со связью один ко многим - Типы документов (10 записей), Шапка документов (1 000 000 записей) и Обьекты документов (10 000 000 записей). На Типы документов вообще кластерный индекс не нужен. На Шапку документов мы например, постоянно в запросах фильтруем и аггрегируем по типу документов и дате выписке. По умолчанию ASA будет использовать индекс внешнего ключа на тип документов. Однако если в среднем на один тип документа приходиться 100 000 шапок документов, то ASA при выполнении такого запроса должна просмотреть 100 000 записей в таблице и наложить фильтр на дату выписки документа. С другой стороны в день выписывается до 100 документов. Значит выгоднее сделать индекс по дате выписки и СУБД используя этот индекс найдет и просмотрит 100 записей в таблице, отфильтровав по типу документа. В шапку документов сами документы добавляются последовательно каждый день, значит индекс по дате является идеальным кандидатом на кластерный индекс, так как он исключает дефрагментирование таблицы. Далее смотрим на таблицу Обьекты Документов. Они зависят от Шапки документов и связанны с ними во всех запросах. В среднем на одну запись в шапке документов присутствует 10 записей в Обьектах документов. Значит наиболее эффективно для ASA будет использование при выполнении запросов индекса FOREIGN KEY. Так как обычно при занесении записи в шапку документа сразу заносятся подробности в обьекты документа, то индекс FOREIGN KEY является лучшим кандидатом на кластерный индекс.

4. Не стоит сильно увлекаться составными индексами. Они хороши для фильтрации, сортировке и группировке по таблице в запросах, но только при условии, что задействованны все поля индекса. Правда если продумать порядок вхождения полей в индекс, то при невхождении в фильтр запроса последних полей индекса ASA сможет им воспользоваться. Вообще про индексы стоит думать как про деревья - чем разветвленней и больше получается дерево, тем сложнее по нему лазить и искать. Соотвествующе во многих запросах частенько видно, как оптимизатор ASA, используя составные индексы, использует поиск только по первым полям этого индекса, отбрасывая остальные поля, которые с нашей точки здравого рассуждения могли и пригодиться. Однако оптимизатор делает более правильно, считая что вместо того, чтобы углубляться в дерево, легче по его верхнему уровню получить предварительный список указателей на записи в таблице и читая их по таблице просто отфильтровать. В качестве примера снова вернемся к примеру из пункта 3: в таблице Шапка документов я сделал кластерным индекс по дате выписки, хотя при выборке оптимизатору приходиться накладывать фильтр по типу документов. Казалось бы можно сделать составной индекс из полей Дата выписки + Тип документа, однако на самом деле это было бы менее эффективно, так как дерево индексов стало более глубоким и искать в нем было бы уже более накладно, чем просто отфильтровав нужные записи таблицы, плюс кластерный индекс уже стал бы частично дефрагментированым, так как нет гарантий, что при вводе записей в шапку документов будет по нарастающей вводиться не только по дате выписки, но и по типу документов.

Ну и на последок хочу заметить, что любая работа оптимизатора, принятие решения им насчет рациональности использования того или иного индекса, а то и TABLE SCAN напрямую зависит от статистики по полям таблиц, поэтому повторюсь - после массовых изменениях данных лучше всего ручками ее пересоздавать.