回顾一些遗留代码,我发现一个查询似乎最好写得不好。以这种方式编写ORDER BY
是否有一些理论上的(性能?)优势?毕竟,SQL Server默认不关心大小写。
SELECT PreferredName
FROM NameList
ORDER BY CAST(LOWER(PreferredName) AS BINARY)
这个问题可能并不重要,但PreferredName
列定义为NVarchar(1000)。
答案 0 :(得分:0)
不,我看不出有什么可能有优势。
这里的问题是ORDER BY不能使用索引列。如果你在PreferredName上添加索引并摆脱CAST和LOWER,我敢打赌你会看到大型数据集的大幅改进。
答案 1 :(得分:0)
不。
同意写得不好。
LOWER
和CAST
函数阻止使用任何索引来避免排序。
此外,强制转换为二进制意味着许多字符不会按照通常的Unicode字符串排序规则在正确的位置排序。
同样,在没有指定任何长度的情况下转换为二进制文件将截断超过15个字符(30个字节)的名称。
答案 2 :(得分:0)
我能看到这样做的唯一原因是我想要排序前N个字符。执行较低的操作然后转换为二进制文件并不能提供任何我能看到的好处。话虽这么说,默认的强制转换长度是每个文档30(BOL),所以它只会在前30个二进制位上排序。也许在进行排序散列时节省了一些时间?