улучшение времени отклика SQL Server

Question

У меня есть таблица, которая содержит около 400 000 записей и которая вызывается на главной странице веб-сайта интрасети. В часы пик у нас может быть 300-400 одновременно работающих пользователей. Инструмент SQL Profiler дает следующий вывод.

• ЦП: 406
• Читает: 32446
• Продолжительность: 397

Я проиндексировал поля, участвующие в предложении where. Есть ли способ улучшить время отклика?

Что нужно сделать, чтобы уменьшить чтение с диска?

Конфигурация сервера: Windows 2003 64-битная, SQL Server 2005 64-битная SP2, .NET 2.0.

Добавлены запрос и определение таблицы ниже. Есть еще около 40 полей, которые я не добавил сюда для простоты. Те поля, которые в основном varchar, не используются в предложении where. Они просто там, чтобы показать на странице. Есть некоторые поля (5-6), которые в настоящее время не используются, но я оставил их в запросе, потому что они потребуются позже. Должен ли я снять их сейчас тогда? это улучшит время отклика?

Запрос

SELECT 
    u.[PeopleKey], 
    u.[EnterpriseId],   
    u.[PersonnelNbr],   
    u.LastName,   
    u.FirstName,   
    u.MiddleName,    
    cc.WorkForceCd AS CareerCounselorWorkForceCd,                     
    cc.WorkForceDesc AS CareerCounselorWorkForceDesc,                    
    cc.WorkGroupCd AS CareerCounselorWorkGroupCd,                   
    cc.WorkGroupDesc AS CareerCounselorWorkGroupDesc,                 
    cc.CareerLevelCd As CareerCounselorCareerLevelCd,               
    cc.CareerLevelDesc AS CareerCounselorCareerLevel,             
    CL.NextLevelCD as  nextCareerLevelCd
FROM 
    [User] u 
    LEFT JOIN [User] cc ON 
        u.[CareerCounselorPeopleKey] = cc.PersonnelNbr  
    Left JOIN [CareerLevel] CLON 
        u.WorkForceCd= CL.WorkForceCd AND 
        u.CareerLevelCd = CL.LevelCd
WHERE 
    u.PeopleKey = <integer>

[CareerLevel]

ID  int 4 [Primary Key - clustered index]
Description varchar 150
WorkforceCd varchar 4
LevelCD varchar     10
NextLevelCD varchar 10

[Пользователь]

PeopleKey   int 4 [Primary Key - clustered index]
EnterpriseId    varchar 50 [non clustered index]
PersonnelNbr    varchar 8 [non clustered index]
FirstName   varchar 40
LastName    varchar 40
MiddleName  varchar 40
CareerCounselorPeopleKey    int 4
CareerCounselorPersonnelNbr varchar 8
CareerCounselorName varchar 50
CapabilityCd    varchar 5
CapabilityDesc  varchar 25
WorkforceCd varchar 4
WorkForceDesc   varchar 40
WorkGroupCd varchar 4
WorkGroupDesc   varchar 50
CareerLevelCd   varchar 10
CareerLevelDesc varchar 50

Answer 1

Можете ли вы опубликовать схему таблицы и определения индекса? Как выглядят ваши запросы?

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

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

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

Марк

Answer 2

Join Left On - все эти столбцы: ON u. [CareerCounselorPeopleKey] = cc.PersonnelNbr Left JOIN [CareerLevel] CL ON u. WorkForceCd = CL. WorkForceCd И u. CareerLevelCd = CL. LevelCd

Как и ваше предложение WHERE, предложение ON предназначено для очевидных ключевых отношений!

Таким образом, столбцы, отмеченные жирным шрифтом, также должны быть проиндексированы ...

Answer 3

Взгляните на Панель управления производительностью SQL Server . Если у вас появятся очевидные проблемы, они появятся там.

Кроме того, вы не должны просто добавлять индексы без анализа плана выполнения запросов (и посмотреть, что он ищет).

Answer 4

Насколько велика ваша БД и сколько у вас оперативной памяти на этом боксе?

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

Если вы запускаете план выполнения запроса в sql management studio, вы видите какие-либо таблицы сканирования (вы хотите, чтобы поиск). Если вы видите сканы, у вас могут отсутствовать индексы.

Какой у вас первичный ключ / кластерный индекс? Можете ли вы переключить свои поиски на использование кластерного индекса? Это всегда ваш самый быстрый маршрут к вашим данным.

Надеюсь, это поможет!