Влияет ли наличие строкового столбца в качестве первичного ключа вместо целочисленного столбца отрицательно на время поиска и / или время вставки?
Сценарии
a.Обычный сценарий для любого приложения состоит в том, чтобы делать этот запрос каждый раз, когда кто-то создает новую учетную запись пользователя:
Это имя пользователя уже существует или оно взято кем-то другим?
б.И когда пользователь входит в систему, требуется выполнить другой запрос, который ищет имя пользователя, следующим образом:
Существует ли строка с этим UserName в таблице User?
с.Точно так же, когда пользователь говорит, что он забыл свой пароль, мы должны выполнить поиск по его электронной почте.
Существует ли строка с этим Email в таблице User?
д.Только в случае связывания таблицы User с другими пользовательскими таблицами, такими как UserRole, UserClaim и т. Д., Нам может потребоваться объединить их на основе целого числа Id, например, так:
SELECT *
FROM User, UserClaim
WHERE User.Id = UserClaim.UserId;
Наличие целого числа в качестве первичного ключа и наличие строки в качестве первичного ключа
До сих пор у меня всегда была только пользовательская таблица с целым числомпервичный ключ (и кластеризованный индекс по нему), например, так:
User
-----
Id int primary key identity(1, 1),
UserName nvarchar(50) not null,
Email nvarchar(100) not null,
PasswordHash nvarchar(32) not null
Однако теперь, рассматривая варианты использования, которые я описал выше, я задаюсь вопросом, будет ли более плодотворным вместо этого полностью исключить целочисленный первичный ключи вместо этого сделайте одно из полей UserName или Email в качестве первичного ключа следующим образом:
User
-----
UserName nvarchar(50) primary key,
Email nvarchar(100) not null,
PasswordHash nvarchar(32) not null
Это создаст кластеризованный индекс в поле UserName, что, вероятно, ускорит запросы в сценариях a и b , перечисленных выше, но я не уверен в сценариях воздействия c и d , поскольку это будет зависеть от скорости или сравнения целых чиселсо скоростью сравнения показателей баsed на строковом столбце.
Вопросы
Тем не менее, это оставляет меня с несколькими потерянными концами, мне нужно связать, прежде чем я смогу совершить на этом проекте:
Имеет ли создание кластеризованного индекса для текстового поля, как указано выше, какие-либо последствия для производительности?Как это влияет на время вставки?Время поиска?
Я мог бы представить, что создание индекса для целого числа быстрее, чем для строки?
У нас может быть только один кластерный индекс.Если я позволю своим пользователям входить в систему, используя имя пользователя или электронную почту, кого угодно, то мне придется выполнять поиск по полям UserName и Email так же часто.Как мне это сделать?Должен ли я создавать некластеризованный индекс для поля Email?
Повлияет ли наличие столбца строки в качестве первичного ключа на производительность соединений, которые я делаю с другими таблицами ссылоквот так:
SELECT * FROM User, UserRole
WHERE User.UserName = UserRole.UserName;
Учитывая # 3, похоже, что я должен просто сохранить целочисленный столбец Id в таблице User и создать некластеризованный индекс каждый настолбцы UserName и Email?
Я использую Microsoft SQL Server 2014.