Как правильно проиндексировать мою базу данных для повышения производительности запросов

Question

Я работаю над простой страницей входа в систему с использованием OpenID: если пользователь только что зарегистрировался для OpenID, то мне нужно создать новую запись в базе данных для пользователя, в противном случае я просто отображаю его псевдоним с приветствием. Каждый раз, когда кто-то проходит проверку подлинности с помощью своего Open ID, я должен найти его псевдоним, посмотрев, у какого пользователя есть данный OpenID, и кажется, что он может быть довольно медленным, если первичным ключом является UserID (а пользователей миллионы).

Я использую SQL Server 2008 и у меня есть две таблицы в моей базе данных (пользователи и OpenID): я планирую проверить, существует ли Open ID в таблице OpenID, а затем использовать соответствующий UserID, чтобы получить остальную часть пользователя информация из таблицы Users.

Таблица Users индексируется по UserID и имеет следующие столбцы:

• UserID (pk)
• EMail
• Псевдоним
• OpenID (fk)

Таблица OpenIDs индексируется OpenID и имеет следующие столбцы:

• OpenID (pk)
• UserID (fk)

В качестве альтернативы, я могу индексировать таблицу Users по UserID и OpenID (т. Е. Иметь 2 индекса) и полностью удалять таблицу OpenID.

Каков рекомендуемый способ улучшения запроса для пользователя с соответствующим OpenID в этом случае: индексировать таблицу Users двумя ключами или использовать таблицу OpenIDs, чтобы найти соответствующий UserID?

Answer 1

Возможно, это ответы на Какие рекомендации и «практические правила» для создания индексов базы данных? могут вам помочь.

Answer 2

Не зная, какие типы запросов вы будете выполнять, я бы порекомендовал проиндексировать два столбца внешнего ключа - Users.OpenID и OpenIDs.UserID.

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

Но, честно говоря, если вы используете таблицу OpenIDs только для проверки существования OpenID, вам будет гораздо лучше просто индексировать (возможно, уникальный индекс?) Этот столбец в таблице Users и покончим с этим. Эта таблица OpenIDs в том виде, в каком она у вас есть, теперь не имеет никакой реальной цели - просто занимает место для избыточной информации.

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

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

На самом деле, совсем наоборот! Если у вас есть уникальное значение среди миллионов строк, то найти это единственное значение довольно быстро - даже для миллионов пользователей. Это займет всего несколько (макс. 5-6) сравнений и взрыв! у вас есть один пользователь из миллиона. Если у вас есть индекс для этого столбца OpenID, это должно быть довольно быстро. Такой высокоселективный индекс (одно значение выбирает 1 на миллион) работает очень и очень эффективно.