collation không hợp lệ SQL Server trường hợp

Question

lợi ích/hạn chế của việc sử dụng một trường hợp collation insensitive trong SQL Server (về hiệu suất truy vấn) là gì?

Tôi có cơ sở dữ liệu hiện đang sử dụng đối chiếu phân biệt chữ hoa chữ thường và tôi thực sự không thích nó. Tôi rất muốn thay đổi nó thành trường hợp nhạy cảm. Tôi nên biết gì khi thay đổi collation?

Answer 1

(Tôi bổ sung này như một câu trả lời riêng biệt vì nó đáng kể khác so với lần đầu tiên của tôi.) Ok, tìm thấy một số tài liệu thực tế. Điều này MS KB article nói rằng có là hiệu suất khác nhau giữa các collations khác nhau, nhưng không phải nơi bạn nghĩ. Sự khác biệt là giữa collations SQL (tương thích ngược, nhưng không phải Unicode aware) và của Windows collations (unicode biết):

Nói chung, mức độ chênh lệch hiệu suất giữa Windows và collations SQL sẽ không được có ý nghĩa. Sự khác biệt chỉ xuất hiện nếu khối lượng công việc bị ràng buộc bởi CPU, thay vì bị ràng buộc bởi I/O hoặc tốc độ mạng, và phần lớn gánh nặng CPU này là do chi phí của thao tác chuỗi hoặc so sánh được thực hiện trong SQL Server.

Cả hai bản sao SQL và Windows đều có phân biệt chữ hoa và chữ thường, vì vậy có vẻ như đó không phải là mối quan tâm chính.

Một câu chuyện hay "từ chiến hào" trong bài viết xuất sắc của Dan với tựa đề "Collation Hell":

tôi thừa hưởng một môi trường đối chiếu hỗn hợp với nhiều collations hơn tôi có thể đếm trên một bàn tay. Các collations khác nhau yêu cầu cách giải quyết để tránh "không thể giải quyết xung đột collation" lỗi và những cách giải quyết giết hiệu suất do biểu thức không sargable. Đối phó với các đối chiếu hỗn hợp là một nỗi đau thực sự vì vậy tôi khuyên bạn nên chuẩn hóa trên một đối chiếu đơn lẻ và chỉ chệch hướng sau khi suy nghĩ cẩn thận.

Ông kết luận:

Cá nhân tôi không nghĩ rằng hiệu suất thậm chí cần được xem xét trong việc lựa chọn đối chiếu thích hợp. Một trong những lý do tôi sống trong địa ngục đối chiếu là những người tiền nhiệm của tôi đã chọn các đối chiếu nhị phân để loại bỏ mọi hiệu suất cho các hệ thống OLTP giao dịch cao của chúng tôi. Với ngoại lệ duy nhất của tìm kiếm quét bảng ký tự đại diện hàng đầu, tôi đã không tìm thấy sự khác biệt về hiệu suất có thể đo lường được với các đối chiếu khác nhau của chúng tôi. Chìa khóa thực sự để thực hiện là truy vấn và điều chỉnh chỉ mục thay vì đối chiếu. Nếu hiệu suất là quan trọng với bạn, tôi khuyên bạn nên thực hiện kiểm tra hiệu suất với các truy vấn ứng dụng thực tế của bạn trước khi bạn chọn một đối chiếu dựa trên kỳ vọng hiệu suất.

Hy vọng điều này sẽ hữu ích.

Answer 2

Tôi có thể nói nhược điểm lớn nhất khi thay đổi đối chiếu trường hợp nhạy cảm trong cơ sở dữ liệu sản xuất là nhiều, nếu không phải là nhiều nhất, truy vấn của bạn sẽ thất bại vì chúng hiện được thiết kế để bỏ qua trường hợp.

Tôi đã không cố gắng thay đổi đối chiếu trên cơ sở dữ liệu hiện có, nhưng tôi cho rằng nó có thể mất nhiều thời gian để thực hiện. Có thể bạn sẽ phải khóa hoàn toàn người dùng của mình trong khi quá trình cũng diễn ra. Đừng thử điều này trừ khi bạn đã kiểm tra kỹ lưỡng về dev.

Answer 3

Nếu bạn thay đổi đối chiếu trên cơ sở dữ liệu, bạn cũng phải thay đổi nó trên từng cột riêng lẻ - chúng duy trì cài đặt đối chiếu có hiệu lực khi bảng của chúng được tạo.

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 

Kết quả:

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

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

Answer 4

Nếu bạn thay đổi collation cơ sở dữ liệu nhưng không phải là đối chiếu máy chủ (và sau đó họ không phù hợp với kết quả là), xem ra khi sử dụng các bảng tạm thời. Trừ khi được quy định trong câu lệnh CREATE của họ, họ sẽ sử dụng collation mặc định của máy chủ hơn là cơ sở dữ liệu có thể gây ra JOIN hoặc các so sánh khác với các cột DB của bạn (giả sử chúng cũng thay đổi đối với collation của DB, như được Damien_The_Unbeliever ám chỉ) thất bại.

Answer 5

tôi không thể tìm thấy bất cứ điều gì để xác nhận liệu xây đúng truy vấn làm việc nhanh hơn trên một case-sensitive vs cơ sở dữ liệu case-insensitive (mặc dù tôi nghi ngờ sự khác biệt là không đáng kể), nhưng một vài điều là rõ ràng với tôi:

1. Nếu yêu cầu kinh doanh của bạn không yêu cầu, bạn đang tự đặt cho mình nhiều công việc phụ (đây là mấu chốt của cả hai câu trả lời của HLGEM và Damien_The_Unbeliever).
2. Nếu yêu cầu kinh doanh của bạn không yêu cầu, bạn đang tự thiết lập cho rất nhiều lỗi có thể xảy ra.
3. của nó cách quá dễ dàng để xây dựng các truy vấn hoạt động kém trong một cơ sở dữ liệu case-insensitive nếu một trường hợp nhạy cảm tra cứu được yêu cầu:

Một truy vấn như:

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

sẽ không sử dụng một chỉ mục trên GivenName. Bạn sẽ nghĩ điều gì đó như:

... WHERE GivenName = 'PETER' COLLATE SQL_Latin1_General_CP1_CS_AS 

sẽ hoạt động tốt hơn và thực hiện. Nhưng đối với hiệu suất tối đa mà bạn sẽ phải làm một cái gì đó như:

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

(thấy this article cho các chi tiết)