invmalexeyvgНаверное, сервер считает, что быстрее просканировать небольшой результат, чем искать пересечение с третьим огромным подмножеством?Так вот это и проблема - получить пересечение двух индексов в объеме, достаточном, чтобы потом *Lookup с фильтрацией не убил производительность. Можете такое гарантировать без ручных оптимизаций?Мы же говорим о рутинных обычных случаях. О простых запросах, как привёл ТС вначале.
Сервер по статистикам сам будет понимать, какая там селективность, что выгоднее, один индекс, или два, и какие именно (например, из 5 полей).
Конечно, он может ошибаться, но вероятность не очень большая, тут же нету наворотов в виде десятков джойнов, и подзапросов с группировками.
И ещё, для таких сложных навороченных запросов и FTS окажется бессильным, правильно?

По крайней мере, создать отдельные индексы может быть неплохой идеей в дополнение к небольшому числу покрывающих инедксов, созданных на основании статистики вызовов.
invmК тому же, асинхронно поддерживать один FTI может оказаться банально выгоднее синхронной поддержки N индексов.Вот не уверен, что при большой нагрузке FTS предпочтительнее.
То есть с точки зрения быстроты выполнения изменяющих запросов без сомнения, но вот общая производительность, нагрузка на сервер, тут не уверен, что лучше.

Но, конечно, стоимость обновлений нужно учитывать, это без сомнения. Думаю, что конкретно у ТС проблема всё таки в чтении/поиске, но тем не менее.

invmmsLexНо при таком типе нагрузке встает вопрос о допустимости асинхронной поддержки индекса, ведь в этом случае асинхронно обновляемый FTI будет быстро терять актуальность.Не обязательно. Много индексов и wide-планы их обновлений уже дадут допнагрузку на tempdb.Обязательно. Обязательно при поиске только что вставленной записи FTS её не найдёт. Так что нужно будет аккуратно. FTS предназначен всё таки для приблизительного, оценочного поиска, он не гарантирует.

invmalexeyvgМы же говорим о рутинных обычных случаях. О простых запросах, как привёл ТС вначале.
Сервер по статистикам сам будет понимать, какая там селективность, что выгоднее, один индекс, или два, и какие именно (например, из 5 полей).Даже в рутинном случае, достаточно заменить несколько and на or чтобы все стало не так радужно.Я не спорю, да и с and оно не радужно, не так, как при поиске по составному индексу.

Я просто писал к тому, что не вижу, почему FTS прои таких же условиях будет искать быстрее. Просто не понимаю, с чего ему быть быстрее.
Глобальные принципы поиска информации компьютером ведь остаются неизменными.
Если бы FTS делал бы индекс по всем комбинациям слов :-) , но такого же не может быть. ИМХО он ищет ровно так же, как обычный индекс. Отличия FTS от обычных индексов в том, что он а) использует промежутоный морфологический справочник, и б) самостоятельно индексирует слова.
А так, в остальном, его принципы поиска не могут быть другими.