Os agrupamentos no SQL Server determinam as regras para correspondência e classificação de dados de caracteres. Normalmente, você escolheria um agrupamento primeiro com base na semântica de comparação e na ordem de classificação exigida pelos consumidores dos dados.

Os humanos geralmente não descobrem que os agrupamentos binários produzem os comportamentos de classificação e comparação que esperam. Portanto, embora elas ofereçam o melhor desempenho (especialmente as versões BIN2 de ponto de código puro), a maioria das implementações não as utiliza.

Em seguida, em termos de desempenho bruto (mas apenas para strings não Unicode) estão os agrupamentos SQL de compatibilidade com versões anteriores . Ao trabalhar com dados Unicode, esses agrupamentos usam um agrupamento do Windows , com as mesmas características de desempenho. Existem armadilhas sutis aqui, então você precisa ter boas razões para escolher um agrupamento SQL hoje em dia (a menos que esteja trabalhando em um sistema americano, onde ainda é o padrão).

Os agrupamentos do Windows são os mais lentos, em geral, devido às complexas regras de comparação e classificação Unicode. No entanto, eles oferecem total compatibilidade com o Windows no SQL Server e são mantidos regularmente para acompanhar as mudanças no padrão Unicode. Para uso moderno que inclui dados Unicode, geralmente é recomendado um agrupamento do Windows.

TL;DR

Se tudo o que você deseja é comparação com distinção entre maiúsculas e minúsculas e semântica de classificação, você deve escolher a _CS_variação (para Diferenciar maiúsculas e minúsculas) de qualquer ordenação de base que forneça o comportamento esperado para o idioma e a cultura de seus usuários. Por exemplo, ambos são agrupamentos que diferenciam maiúsculas de minúsculas:

-- Latin1-General, case-sensitive, accent-sensitive
Latin1_General_CS_AS 

-- Latin1-General, case-sensitive, accent-sensitive for Unicode Data, 
-- SQL Server Sort Order 51 on Code Page 1252 for non-Unicode Data
SQL_Latin1_General_CP1_CS_AS

Você pode ver essas definições usando sys.fn_helpcollations

Exemplos

Quatro tabelas que são exatamente iguais, exceto pelo agrupamento; um binário, um que diferencia maiúsculas de minúsculas, um que não diferencia maiúsculas de minúsculas e um SQL que diferencia maiúsculas de minúsculas:

CREATE TABLE #Example_BIN
(
    string nvarchar(50) 
        COLLATE Latin1_General_BIN
        NOT NULL
);

CREATE TABLE #Example_CS
(
    string nvarchar(50) 
        COLLATE Latin1_General_CS_AI
        NOT NULL
);

CREATE TABLE #Example_CI
(
    string nvarchar(50) 
        COLLATE Latin1_General_CI_AI
        NOT NULL
);

CREATE TABLE #Example_SQL
(
    string varchar(50) -- Note varchar
        COLLATE SQL_Latin1_General_CP1_CS_AS
        NOT NULL
);

Mesmos dados de amostra para cada tabela:

INSERT #Example_BIN
    (string)
VALUES
    (N'A'),
    (N'a'),
    (N'B'),
    (N'b'),
    (N'C'),
    (N'c');

INSERT #Example_CS
SELECT EB.string 
FROM #Example_BIN AS EB;

INSERT #Example_CI
SELECT EB.string 
FROM #Example_BIN AS EB;

INSERT #Example_SQL
SELECT EB.string 
FROM #Example_BIN AS EB;

Agora queremos encontrar strings maiores que 'a':

SELECT EB.string AS BIN
FROM #Example_BIN AS EB
WHERE EB.string > N'a'
ORDER BY EB.string;

SELECT EC.string AS CS
FROM #Example_CS AS EC
WHERE EC.string > N'a'
ORDER BY EC.string;

SELECT EC2.string AS CI
FROM #Example_CI AS EC2
WHERE EC2.string > N'a'
ORDER BY EC2.string;

SELECT ES.string AS SQL
FROM #Example_SQL AS ES
WHERE ES.string > 'a' -- not Unicode
ORDER BY ES.string;

Resultados:

╔═════╗
║ BIN ║
╠═════╣
║ b   ║
║ c   ║
╚═════╝

╔════╗
║ CS ║
╠════╣
║ A  ║
║ b  ║
║ B  ║
║ c  ║
║ C  ║
╚════╝

╔════╗
║ CI ║
╠════╣
║ B  ║
║ b  ║
║ C  ║
║ c  ║
╚════╝

╔═════╗
║ SQL ║
╠═════╣
║ B   ║
║ b   ║
║ C   ║
║ c   ║
╚═════╝

Finalmente...

Observe que, se usarmos um literal Unicode com o agrupamento SQL, as regras de conversão implícitas resultarão em uma comparação de agrupamento do Windows:

SELECT ES.string AS SQL
FROM #Example_SQL AS ES
WHERE ES.string > N'a'
ORDER BY ES.string;

... e os resultados do agrupamento SQL mudam :

╔═════╗
║ SQL ║
╠═════╣
║ A   ║
║ B   ║
║ b   ║
║ C   ║
║ c   ║
╚═════╝

Dado que este é um banco de dados existente que já possui tabelas definidas nele, existem algumas implicações muito sérias para a ação de alterar o agrupamento do banco de dados, além do impacto potencial no desempenho das operações DML (que na verdade já estava lá). Há um impacto muito real no desempenho e na funcionalidade, e essa mudança não apenas não atingiu o objetivo pretendido (pelo menos não de forma consistente), mas provavelmente alterou o comportamento (ou alterará o comportamento quando novas tabelas são criadas) em termos de como os dados são ordenados e equacionados.

Paul já forneceu boas explicações e exemplos das diferenças de desempenho e comportamento entre os diferentes tipos de agrupamentos em sua resposta, então não vou repetir isso aqui. No entanto, alguns pontos precisam de alguns detalhes adicionais, e há vários outros pontos a serem adicionados em relação ao cenário atual de alteração do agrupamento de um banco de dados existente, em vez de definir o agrupamento de um novo banco de dados.

1. Os agrupamentos binários são mais do que apenas diferenciam maiúsculas de minúsculas: eles são sensíveis a tudo ! Portanto, usando um agrupamento binário (terminando em _BINou _BIN2), suas comparações agora também são sensíveis ao acento, sensíveis ao kana, sensíveis à largura e potencialmente sensíveis ao glúten (pelo menos essa parece ser a tendência nos dias de hoje ;-) ). Este foi o efeito desejado de fazer essa mudança? Os usuários finais estão esperando essa mudança de comportamento?

2. Os agrupamentos afetam não apenas as comparações, mas também a classificação. Uma ordenação binária será classificada com base no valor do byte ASCIIou UNICODE(dependendo de VARCHARou NVARCHAR, respectivamente) de cada byte . Portanto, ao escolher um agrupamento binário, você está desistindo de regras de ponderação específicas de idioma/cultura que ordenam cada caractere (mesmo caracteres em algum idioma, como o húngaro, que são compostos por 2 letras) de acordo com o alfabeto dessa cultura. Então, se "ch" deve vir naturalmente depois de "k", bem, isso não vai acontecer usando um agrupamento binário. Novamente, este foi o efeito desejado de fazer essa mudança? Os usuários finais estão esperando essa mudança de comportamento?

3. A menos que você tenha requisitos específicos de compatibilidade com versões anteriores para seu aplicativo, você deve usar o BIN2em vez de BINagrupamentos, assumindo, é claro, que você deseja um agrupamento binário em primeiro lugar. Os BIN2agrupamentos foram introduzidos no SQL Server 2005 e de acordo com a página do MSDN para Diretrizes para uso de agrupamentos BIN e BIN2 :

   Os agrupamentos binários anteriores no SQL Server, aqueles que terminam com "_BIN", realizaram uma comparação ponto a ponto de código incompleta para dados Unicode. Os agrupamentos binários mais antigos do SQL Server compararam o primeiro caractere como WCHAR, seguido por uma comparação byte por byte.

   ...

   Você pode migrar para os agrupamentos binários [_BIN2] para aproveitar as verdadeiras comparações de pontos de código e deve usar os novos agrupamentos binários para o desenvolvimento de novos aplicativos.

   Também deve ser observado que os _BIN2agrupamentos correspondem convenientemente ao comportamento da Ordinalopção da StringComparison Enumeration , de modo que as comparações e ordenações feitas no código .NET usando essa opção produzirão os mesmos resultados que as mesmas operações executadas no SQL Server (ao usar as _BIN2colações, é claro).

4. Por razões semelhantes ao que acaba de ser declarado sobre os _BIN2agrupamentos, a menos que você tenha requisitos específicos para manter o comportamento de compatibilidade com versões anteriores, você deve usar os agrupamentos do Windows e não os agrupamentos específicos do SQL Server (ou seja, os que começam com SQL_agora são considerados meio "sujo" ;-) ).

5. Ao usar dados Unicode (ou seja, string prefixada com Nou entrando no SQL Server do código do aplicativo em que o tipo de dados foi especificado como NCharou NVarChar), não vejo como usar um agrupamento versus outro faria diferença para inserir ou atualizar um campo NCHARou NVARCHARstring .

   Ao usar dados não Unicode ou inserir ou atualizar um campo não Unicode, o agrupamento específico (banco de dados ou campo) pode desempenhar um papel pequeno se algum caractere inserido/atualizado precisar ser traduzido ou não for mapeável (é que mesmo uma palavra?), conforme especificado pela página de código que é definida pelo agrupamento. Obviamente, esse problema potencial existe sempre que alguém está usando dados ou tipos de dados não Unicode e não é específico para esse cenário de alteração do agrupamento de banco de dados. Essa alteração afetará os literais de string (o que já pode ter sido um problema se o agrupamento do banco de dados fosse diferente do agrupamento do campo). Mas mesmo que nenhuma alteração seja feita no agrupamento de banco de dados, os dados provenientes de outros bancos de dados ou de fora do SQL Server (qualquer código de cliente) podem conter quaisquer caracteres e ser de qualquer codificação específica.

6. MUITO IMPORTANTE!!! Ao alterar o agrupamento padrão do banco de dados, o agrupamento especificado para quaisquer campos de string existentes em qualquer tabela existente não será alterado, mas quaisquer novos campos terão um agrupamento do padrão do banco de dados (a menos que substituído por meio da COLLATEcláusula). Isso afetará suas consultas de três maneiras:

   1) Se qualquer consulta JOIN em qualquer um desses campos existentes para qualquer um dos novos campos, você receberá um erro de incompatibilidade de agrupamento:

   USE [master];
   GO
   
   IF (DB_ID(N'ChangeCollationTest') IS NOT NULL)
   BEGIN
       PRINT 'Dropping [ChangeCollationTest] DB...';
       ALTER DATABASE [ChangeCollationTest]
           SET SINGLE_USER
           WITH ROLLBACK IMMEDIATE;
   
       DROP DATABASE [ChangeCollationTest];
   END;
   GO
   
   PRINT 'Creating [ChangeCollationTest] DB...';
   CREATE DATABASE [ChangeCollationTest]
       COLLATE SQL_Latin1_General_CP1_CI_AS;
   GO
   
   USE [ChangeCollationTest];
   GO
   
   CREATE TABLE [CollateTest-SQL_Latin1_General_CP1_CI_AS]
                (Col1 NVARCHAR(50) COLLATE DATABASE_DEFAULT, Col2 NVARCHAR(50));
   SELECT *
   FROM   sys.columns sc
   WHERE  sc.[object_id] = OBJECT_ID(N'[CollateTest-SQL_Latin1_General_CP1_CI_AS]');
   -- "collation_name" for both fields shows: SQL_Latin1_General_CP1_CI_AS
   GO
   
   USE [master];
   GO
   ALTER DATABASE [ChangeCollationTest]
       COLLATE Latin1_General_BIN2;
   GO
   USE [ChangeCollationTest];
   GO
   
   CREATE TABLE [CollateTest-Latin1_General_BIN2]
                (Col1 NVARCHAR(50) COLLATE DATABASE_DEFAULT, Col2 NVARCHAR(50));
   SELECT *
   FROM   sys.columns sc
   WHERE  sc.[object_id] = OBJECT_ID(N'[CollateTest-Latin1_General_BIN2]');
   -- "collation_name" for both fields shows: Latin1_General_BIN2
   GO
   
   
   SELECT *
   FROM   dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] ctSQL
   INNER JOIN  dbo.[CollateTest-Latin1_General_BIN2] ctWIN
           ON  ctWIN.Col1 = ctSQL.Col1;
   

   Devoluções:

   Msg 468, Level 16, State 9, Line 4
   Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CI_AS" and
   "Latin1_General_BIN2" in the equal to operation.
   

   2) Predicados/filtros em campos existentes de tabelas existentes (definidos para o agrupamento padrão anterior) que se comparam a literais ou variáveis ​​de string não apresentarão erros, mas certamente podem ser afetados em termos de desempenho devido ao SQL Server precisar igualar o agrupamento de ambos os lados e convertendo automaticamente a string literal ou variável para o agrupamento do campo. Habilite "Incluir Plano de Execução Real" (Control-M) e execute o seguinte (supondo que você já tenha executado as consultas mostradas acima):

   SELECT *
   FROM   dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] ctSQL
   WHERE  ctSQL.Col1 = N'a';
   -- Unspecified collations on string literals and variables assume the database default
   -- collation. This mismatch doesn't cause an error because SQL Server adds a
   -- "[Col1]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)" but it can hurt performance.
   
   SELECT *
   FROM   dbo.[CollateTest-Latin1_General_BIN2] ctWIN
   WHERE  ctWIN.Col1 = N'a';
   -- No CONVERT_IMPLICIT; plan shows "[Col1]=[@1]".
   

   3) E, falando de conversões implícitas, observe como é a string literal (com uma ordenação implícita da ordenação padrão do banco de dados: Latin1_General_BIN2) que é convertida, não o campo na tabela. Algum palpite sobre se esse filtro não diferencia maiúsculas de minúsculas (o agrupamento antigo) ou diferencia maiúsculas de minúsculas (o novo agrupamento)? Execute o seguinte para ver:

   INSERT INTO dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] (Col1)
   VALUES (N'a'), (N'A');
   
   SELECT ctSQL.Col1
   FROM   dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] ctSQL
   WHERE  ctSQL.Col1 = N'a';
   

   Devoluções:

   Col1
   ----
   a
   A
   

   D'oh! Não apenas há um pequeno (ou talvez mais significativo?) impacto no desempenho para essa consulta devido ao CONVERT_IMPLICIT(), mas ela nem se comporta da maneira desejada com distinção entre maiúsculas e minúsculas.

   Portanto, se o agrupamento for alterado em um banco de dados que já possui tabelas, sim, tanto o desempenho quanto a funcionalidade serão afetados.

   Se a ordenação está sendo definida em um novo banco de dados, Paul já cobriu isso explicando como uma ordenação binária, embora rápida, provavelmente não será classificada da maneira que se esperaria ou desejaria.

Também deve ser observado que você sempre pode especificar agrupamentos por condição. A cláusula COLLATEWHERE pode ser adicionada a condições, ORDER BYe a quase todos os locais que aceitam uma string.

Exemplo 1 (condição WHERE):

SELECT tmp.col AS [SQL-CaseSensitive]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
WHERE tmp.col > 'a' COLLATE SQL_Latin1_General_CP1_CS_AS;

SELECT tmp.col AS [Windows-CaseSensitive]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
WHERE tmp.col > 'a' COLLATE Latin1_General_CS_AI;

Devoluções:

SQL-CaseSensitive
-----------------
b
B

Windows-CaseSensitive
-----------------
A
b
B

Exemplo 2 (ORDEM POR):

SELECT tmp.col AS [Windows-CaseSensitive]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
ORDER BY tmp.col COLLATE Latin1_General_CS_AI;

SELECT tmp.col AS [Windows-Binary]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
ORDER BY tmp.col COLLATE Latin1_General_BIN2;

Devoluções:

Windows-CaseSensitive
-----------------
a
A
b
B

Windows-Binary
-----------------
A
B
a
b

Exemplo 3 (instrução SE):

IF ('A' = 'a') SELECT 1 AS [DatabaseDefault-CaseInsensitive?];
-- if the DB is not case-sensitive or binary, returns 1

IF ('A' = 'a' COLLATE Latin1_General_BIN2) SELECT 2 AS [Windows-Binary];

Devoluções:

DatabaseDefault-CaseInsensitive?
--------------------------------
1

{nothing}

Exemplo 4 (associado ao parâmetro de entrada da função):

SELECT  UNICODE(N'?') AS [UCS-2],
        UNICODE(N'?' COLLATE Latin1_General_100_CI_AS_SC) AS [UTF-16];
-- This character is a Unicode supplemental character and is not part of the
-- default UCS-2 encoding. In order for built-in functions to handle these
-- characters correctly, either the DB default collation needs to end in
-- "_SC" (available as of SQL Server 2012), or use as shown here.
-- See the character in more detail here: http://unicode-table.com/en/1F0A1/

Devoluções:

UCS-2    UTF-16
------   -------
55356    127137

The UCS-2 value of 55,356 is partially correct in that it is the first of the two values in the "surrogate pair". But unless explicitly given the _SC collation, the UNICODE() function can only see each character as a double-byte value and doesn't know how to properly handle a double double-byte surrogate pair.

UPDATE

Even with all of the examples above, one aspect of Case Sensitive comparisons that is usually overlooked, and is negated by binary comparisons / collations, is normalization (composition and decomposition) that is part of Unicode.

Example 5 (when a binary comparison is not case-sensitive):

True case-sensitive comparisons allow for combining characters that, in combination with another character, form yet another character that already exists as another Unicode code point. Case-sensitive comparisons care about the displayable character, not the code point(s) used to create it.

SELECT 'Equal' AS [Binary],
       NCHAR(0x00FC) AS [ü],
       N'u' + NCHAR(0x0308) AS [u + combining diaeresis]
WHERE  NCHAR(0x00FC) COLLATE Latin1_General_100_BIN2
    =  N'u' + NCHAR(0x0308) COLLATE Latin1_General_100_BIN2
-- No result as they are a different number of code points,
-- as well as being different code points.

SELECT 'Equal' AS [Case-Sensitive],
       NCHAR(0x00FC) AS [ü],
       N'u' + NCHAR(0x0308) AS [u + combining diaeresis]
WHERE  NCHAR(0x00FC) COLLATE Latin1_General_100_CS_AS -- ü
    =  N'u' + NCHAR(0x0308) COLLATE Latin1_General_100_CS_AS -- u + combining diaeresis
-- Result set returned, even being a different number of code points AND Accent Sensitive,
-- due to normalization

Returns:

Binary            ü     u + combining diaeresis
-------          ---   -------------------------
{nothing}

Case-Sensitive    ü     u + combining diaeresis
---------------  ---   -------------------------
Equal             ü     ü

True case-sensitive comparisons also allow for wide characters to equate to their non-wide equivalents.

IF (N'ｓｏｆｉａ' = N'sofia' COLLATE Latin1_General_100_BIN2)
  SELECT 'Values are the same' AS [Binary]
ELSE
  SELECT 'Values are different' AS [Binary];


IF (N'ｓｏｆｉａ' = N'sofia' COLLATE Latin1_General_100_CS_AS)
  SELECT 'Values are the same' AS [Case-Sensitive]
ELSE
  SELECT 'Values are different' AS [Case-Sensitive];

Returns:

Binary
---------------
Values are different


Case-Sensitive
---------------
Values are the same

Ergo:

BINARY (_BIN and _BIN2) collations are not Case-Sensitive!