Сортировка без учета регистра в SQL Server

Question

Каковы преимущества / недостатки использования сортировки без учета регистра в SQL Server (с точки зрения производительности запросов)?

У меня есть база данных, в которой в настоящее время используется сортировка без учета регистра, и она мне не очень нравится. Я бы очень хотел изменить его на регистр. О чем следует помнить при изменении параметров сортировки?

Answer 1

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

create database CollTest COLLATE Latin1_General_CI_AI
go
use CollTest
go
create table T1 (
    ID int not null,
    Val1 varchar(50) not null
)
go
select name,collation_name from sys.columns where name='Val1'
go
alter database CollTest COLLATE Latin1_General_CS_AS
go
select name,collation_name from sys.columns where name='Val1'
go

Результат:

name collation_name
---- --------------
Val1 Latin1_General_CI_AI

name collation_name
---- --------------
Val1 Latin1_General_CI_AI

Answer 2

(Я добавил это как отдельный ответ, потому что он существенно отличается от моего первого.) Хорошо, нашел некоторую фактическую документацию.В этой статье MS KB говорится, что имеют различия в производительности между различными параметрами сортировки, но не там, где вы думаете.Разница между сопоставлениями SQL (обратная совместимость, но не поддерживает юникод) и сопоставлениями Windows (юникодная поддержка):

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

В сопоставлениях SQL и Windows есть регистрозависимые и нечувствительные к регистру версии, так что, похоже, это не главное.

Еще одна хорошая история "из окопов" в превосходной статье Дэна под названием " Collation Hell":

Я унаследовал смешанную среду сопоставления с большим количеством сопоставлений, чем я могу рассчитывать с одной стороны.Различные параметры сортировки требуют обходных путей, чтобы избежать ошибок «не удается разрешить конфликт параметров сортировки», и эти обходные пути снижают производительность из-за невыражаемых выражений.Работа со смешанными сопоставлениями - это настоящая боль, поэтому я настоятельно рекомендую вам стандартизировать единственное сопоставление и отклоняться только после тщательного обдумывания.

Он приходит к выводу:

Я лично неЯ думаю, что производительность должна учитываться при выборе правильного сопоставления.Одна из причин, по которой я живу в аду сортировки, заключается в том, что мои предшественники выбрали двоичные параметры сортировки, чтобы получить максимальную производительность для наших высокотранзакционных OLTP-систем.За исключением единственного поиска по шаблону поиска по шаблону, я не обнаружил ощутимой разницы в производительности с нашими различными параметрами сортировки.Реальный ключ к производительности - это настройка запросов и индексов, а не сопоставление.Если для вас важна производительность, я рекомендую вам выполнить тест производительности с фактическими запросами приложений, прежде чем выбирать параметры сортировки на основе ожиданий производительности.

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

Answer 3

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

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

Answer 4

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

1. Если ваши бизнес-требования не требуют этого, вы выполняете много дополнительной работы (суть ответы HLGEM и Damien_The_Unbeliever).
2. Если ваши бизнес-требования не требуют этого, вы настраиваете себя на множество возможных ошибок.
3. Слишком легко создавать плохо выполняющиеся запросы в базе данных без учета регистра, если требуется поиск чувствительный к регистру :

запрос типа:

... WHERE UPPER(GivenName) = 'PETER'

не будет использовать индекс для GivenName. Вы могли бы подумать что-то вроде:

... WHERE GivenName = 'PETER' COLLATE SQL_Latin1_General_CP1_CS_AS

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

... WHERE GivenName = 'PETER' COLLATE SQL_Latin1_General_CP1_CS_AS
    AND GivenName LIKE 'PETER'

(подробности см. в этой статье )

Answer 5

Если вы измените параметры сортировки базы данных, но не параметры сортировки сервера (и в результате они не совпадут), следите за использованием временных таблиц.Если иное не указано в их операторе CREATE, они будут использовать параметры сортировки по умолчанию сервера, а не базы данных, что может привести к JOIN-соединениям или другим сопоставлениям со столбцами вашей БД (при условии, что они также изменены на параметры сортировки БД, на что ссылается Damien_The_Unbeliever)потерпеть неудачу.