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

我想说在生产数据库中更改为区分大小写的排序规则的最大缺点是,许多(如果不是大多数)您的查询会失败,因为它们目前被设计为忽略大小写.

我没有尝试更改现有数据库的排序规则,但我怀疑它也可能非常耗时.在过程发生时,您可能必须完全锁定用户.除非你在dev上进行了彻底的测试,否则不要试试这个.

Answer 3

(我把它作为一个单独的答案添加,因为它与我的第一个完全不同.)好的,找到了一些实际的文档.这个MS KB文章说,有有不同的排序规则之间的性能差异,但不是你想的.区别在于SQL排序规则(向后兼容,但不能识别unicode)和Windows排序规则(可识别unicode):

通常,Windows和SQL排序规则之间的性能差异程度不会很大.仅当工作负载受CPU限制而不受I/O或网络速度限制时才会出现差异,并且此CPU负担的大部分是由字符串操作的开销或SQL Server中执行的比较引起的.

SQL和Windows排序规则都具有区分大小写和不区分大小写的版本,因此听起来这不是主要关注点.

Dan的优秀文章" Collat​​ion Hell "中的另一个好故事"来自战壕":

我继承了一个混合整理环境,其中一方面比我可以计算的排序更多.不同的排序规则需要使用变通方法来避免"无法解决排序规则冲突"错误,并且这些变通方法会因非表达式而导致性能下降.处理混合校对是一种真正的痛苦,因此我强烈建议您对单一校对进行标准化,并且只有在仔细考虑之后才会出现偏差.

他的结论是:

我个人认为在选择合适的校对时甚至不应考虑性能.我生活在整理地狱的原因之一是我的前辈们选择二进制排序规则来为我们的高度事务性OLTP系统提供所有性能.除了领先的通配符表扫描搜索之外,我发现我们的不同排序规则没有可衡量的性能差异.性能的真正关键是查询和索引调整而不是整理.如果性能对您很重要,我建议您在根据性能预期选择排序规则之前,使用实际应用程序查询执行性能测试.

希望这可以帮助.