Проблема производительности SQL Server Express

Question

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

Итак ...

У меня есть база данных SQL Server Express объемом 500 Мб. Он содержит 5 таблиц и, возможно, 30 хранимых процедур. Эта база данных используется для хранения статей и используется для веб-сайта Developer It . Обычно веб-страницы загружаются быстро, скажем, через 2 секунды. НО, процесс sqlserver использует 100% процессора в течение этих 2 или 3 секунд.

Я пытаюсь найти проблему с хранимой процедурой, но не могу ее найти. Кажется, что каждое чтение в таблице содержит статьи (их около 155 000, и каждые 15 минут добавляется около 20).

Я добавил несколько индексов, но без удачи ...

Это потому, что таблица полнотекстовая проиндексирована? Должен ли я иметь заказ с первичным ключом вместо даты? У меня никогда не было проблем с заказом по датам .... Должен ли я использовать динамический SQL? Должен ли я добавить первичный ключ в URL статей? Должен ли я использовать несколько индексов для отдельных столбцов или один большой индекс?

Если вам нужны дополнительные сведения или биты кода, просто попросите об этом.

По сути, каждый маленький намек очень ценится.

Спасибо.

Answer 1

Если ваш индекс не используется, то он обычно указывает на одну из двух проблем:

1. Невыносимые условия предиката, такие как WHERE DATEPART(YY, Column) = <something>. Обтекание столбцов в функции ухудшит или исключит способность оптимизатора эффективно использовать индекс.

2. Не покрытые столбцы в списке вывода, что весьма вероятно, если вы привыкли писать SELECT * вместо SELECT specific_columns. Если индекс не охватывает ваш запрос, то SQL Server должен выполнить поиск RID / ключа для каждой строки, одну за другой, что может настолько сильно замедлить запрос, что оптимизатор просто решит вместо этого выполнить сканирование таблицы.

Посмотрите, может ли один из них относиться к вашей ситуации; если вы все еще в замешательстве, я бы порекомендовал обновить вопрос, добавив дополнительную информацию о вашей схеме, данных и медленных запросах. 500 МБ очень мало для базы данных SQL, поэтому это не должно быть медленным. Также опубликуйте, что находится в плане выполнения.

Answer 2

Используйте SQL Profiler для захвата множества типичных запросов, используемых в вашем приложении.Затем запустите результаты профилировщика с помощью мастера настройки индекса.Это скажет вам, какие индексы можно добавить для оптимизации.

Затем посмотрите на худшие запросы и проанализируйте их планы выполнения вручную.