Индексирование SQLServer для критериев поиска

Question

В базе данных sqlserver 2008 у нас есть таблица с 10 столбцами.В веб-приложении пользовательский интерфейс предназначен для того, чтобы пользователь мог указать критерии поиска для некоторых или всех столбцов.Веб-приложение вызывает хранимую процедуру, которая динамически создает инструкцию sql только с указанными параметрами в предложении where, а затем выполняет запрос, используя sp_executesql.

Каков наилучший способ индексации этих столбцов?В настоящее время у нас есть 10 индексов, каждый из которых имеет свой столбец.Должен ли мы иметь 1 индекс со всеми 10 или какую-то другую комбинацию?

Answer 1

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

В частности, если столбец A запрашивается много, а столбец B имеет тенденцию запрашиваться только при запросе столбца A, составной индекс (A, B) сделает запросы, которые ищут конкретные значения обоих столбцов очень быстро , а также дает вам преимущества единого индекса на А (но не на В) бесплатно.

Возможно, что один индекс на столбец имеет смысл для ваших данных, но, скорее всего, нет. Вероятно, будет лучший компромисс с учетом характера ваших данных и схемы.

Лично я бы не стал использовать хранимую процедуру для создания динамического SQL. Нет никакой выгоды в производительности по сравнению с выполнением этого на любом языке сценариев на стороне сервера, который вы используете в самом веб-приложении, и язык, на котором вы пишете веб-приложение, почти всегда будет иметь более гибкие, читаемые и безопасные функции обработки строк, чем SQL делает. Генерация строк SQL в самом SQL - это трудная задача; почти наверняка вы где-нибудь ошибетесь и получите дыру в безопасности SQL-инъекций.

Answer 2

Библию по оптимизации запросов динамического поиска написал MVP для SQL Server Эрланд Соммарског:

http://www.sommarskog.se/dyn-search.html

Специально для SQL Server 2008:

http://www.sommarskog.se/dyn-search-2008.html

Здесь много информации, которую нужно переварить, и то, что вы в конечном итоге решите, будет зависеть от того, как сформированы запросы.Существуют ли определенные параметры, по которым всегда производится поиск?Существуют ли определенные комбинации параметров, которые обычно запрашиваются вместе?Можете ли вы позволить себе создать индекс для каждого столбца (помните, что не все будут использоваться [ edit ] обязательно , даже если в предложении where указано несколько столбцов, а дополнительные индексыне "бесплатно" - вы платите за них в обслуживании)?

Answer 3

Составной индекс можно использовать только в том случае, если в условии поиска указан крайний левый ключ. Если у вас есть индекс на (A, B, C), его можно использовать для поиска значений WHERE A =@a, WHERE A=@a AND B=@b, WHERE A=@a AND C=@c или WHERE A=@a AND B=@b AND C=@c. Но его нельзя использовать, если крайний левый ключ не указан, WHERE B=@b или WHERE C=@c не может использовать этот индекс. Поэтому каждый из 10 индексов в столбце может использоваться для каждого критерия пользователя, но 1 индекс на 10 столбцов будет полезен только в том случае, если пользователь включает критерии в первый столбец, и бесполезен во всех других случаях. По крайней мере, это 10000-футовый ответ. Если вы начнете копаться в этом, вы узнаете больше подробностей.

Подробное обсуждение вашей проблемы и возможных решений см. Условия динамического поиска в T-SQL .

Answer 4

По моему опыту, объединение индексов делает запросы быстрее. В этом случае вы не можете иметь все возможные комбинации.

Я бы предложил провести некоторое тестирование использования, чтобы определить, какие комбинации используются наиболее часто. Затем сфокусируйтесь на индексах, которые объединяют эти столбцы. Если наиболее частые комбинации:

С1, С2, С3 С1, С2, С5

... затем создайте объединенный индекс для C1 и C2.

Answer 5

Один индекс на столбец.Проблема в том, что вы понятия не имеете о запросах, и это наиболее общий способ.