msLex3. Самое сложное.
Нужно понять, скорости работы при указании (не null) каких из параметров этой процедуры вы ожидаете.
Какие их комбинации устанавливаются одновременно.
Исходя из этого создать нужные индексы.

Например,
1. Вы выяснили, что самым частым случаем является поиск по фамилии, иногда добавляют имя
Сделали индекс по полям F, N

2. Дату рождения у вас всегда ищут как день + месяц, иногда уточняют год
Сделали индекс по полям dd, mm, yyyПомню, накапливал статистику для подобного случая. Потом сделал несколько индексов, покрывающих 99% запросов.

TaPaKalexeyvgПомню, накапливал статистику для подобного случая. Потом сделал несколько индексов, покрывающих 99% запросов.
если объёмы не фантастика, то можно и от обратного, наклепать, через месяц удалить не используемые :)Дык сколько их делать, сотню? Комбинаций то много.

АлексашаmsLex,


msLexНапример,
1. Вы выяснили, что самым частым случаем является поиск по фамилии, иногда добавляют имя
Сделали индекс по полям F, N


Индекс покрывающий т.е. 2 поля? Не два индекса по одному полю в каждом?Да. Собстьвенно, индекс по мм вряд ли имеет смысл делать отдельно, селективность низкая.
Ну и вообще, индекс на несколько полей всегда лучше, если все эти поля используются в запросе.

Владислав КолосовНеужели планируются запросы, возвращающие строки только по первым числам или по декабрям?Всё правильно, ну вот и нужно понять, какие сочетания обычны, а какие невероятны.
Как понять? Наверное, лучше всего собрать статистику, потому что для каждой предметной области типичны свои сочетания.

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

invmДобавляется вычисляемый столбец с, например, таким содержимым


и по нему строится полнотекстовый индекс с отключенным стоп-листом.А чем это будет эффективнее отдельных индексов по полям?
Веть FTS будет искать в индексе наборы про нескольким значениям (словам), и искать пересечение.
И сиквел может искать по нескольким обычным индексам подмножества, и искать пересечение.
Может, в FTS это делается эффективнее, но мне не верится, ядро из 90-х они пока в своих надстройках не превзошли :-)

invmalexeyvgВеть FTS будет искать в индексе наборы про нескольким значениям (словам), и искать пересечение.
И сиквел может искать по нескольким обычным индексам подмножества, и искать пересечение.При использовании множества индексов по столбцам:
- как часто вы наблюдали план, в котором оптимизатор самостоятельно решил строить пересечение более чем двух индексов?
- каким образом обеспечить неизменность запроса при добавлении/удалении/усложнении критериев поиска?Более двух не видел, но разве этого мало? Наверное, сервер считает, что быстрее просканировать небольшой результат, чем искать пересечение с третьим огромным подмножеством?
Вот как сервер ищет в FTS? Он точно будет джойнить три независимых поиска, или ограничится двумя, и отфильтрует результат?
Думаю, что оптимальный путь зависит от конкретных данных.

Второй пункт не понял, зачем обеспечивать неизменность?

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

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

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

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

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

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