So sánh SQL collations cho Windows collations

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:322112
TÓM TẮT
Trong Microsoft SQL Server 2000 và trong Microsoft SQL Server 2005, một "collation" xác định cách thức chuỗi so sánh và được sắp xếp, và những gì ký tự thiết lập được sử dụng cho dữ liệu không dùng Unicode. SQL Server 2000 hoã trôï hai collations:
  • SQL collations
  • Windows collations
Cho một mô tả của từng loại collation và một tốt Tổng quan về làm thế nào để quyết định collation để sử dụng, xem các chủ đề "Chọn Collations" trong SQL Server 2000 cuốn sách trực tuyến, hoặc xem chủ đề "Collation loại" trong SQL Server 2005 sách trực tuyến.

Bài viết này thảo luận về cân nhắc bổ sung mà có thể ảnh hưởng đến của bạn quyết định về việc liệu để chọn một collation Windows hoặc một SQL collation khi bạn cài đặt SQL Server 2000 hoặc SQL Server 2005.
THÔNG TIN THÊM

Collation ngữ nghĩa

Đối với một Windows collation, một so sánh dữ liệu không dùng Unicode là thực hiện bằng cách sử dụng các thuật toán tương tự như Unicode dữ liệu. Cả hai Unicode và không dùng Unicode phân loại là tương thích với chuỗi so sánh quy định đặc biệt một Phiên bản của Windows. Điều này cung cấp nhất quán trên các kiểu dữ liệu trong SQL Server. Nó cũng cho phép các nhà phát triển những người sử dụng các CompareString Win32 API chức năng để sắp xếp chuỗi trong các ứng dụng bằng cách sử dụng các cùng một quy tắc sử dụng SQL Server.

Trong một collation SQL, SQL Server định nghĩa ngữ nghĩa khác nhau so sánh dữ liệu không dùng Unicode. Các căn cứ của SQL Server những ngữ nghĩa so sánh trên một SQL "phân loại đặt hàng." Đối với một bản đồ của đơn đặt hàng loại để SQL collations, xem chủ đề "SQL Collation tên" trong SQL Server Books Trực tuyến.

Quy tắc này một collation SQL để phân loại dữ liệu không dùng Unicode không tương thích với bất kỳ thói quen loại được cung cấp bởi Microsoft Windows hệ điều hành; Tuy nhiên, phân loại dữ liệu Unicode là tương thích với một Phiên bản đặc biệt của các cửa sổ phân loại quy tắc. Bởi vì các quy tắc so sánh Đối với phi-Unicode và Unicode dữ liệu là khác nhau, khi bạn sử dụng một collation SQL bạn có thể nhìn thấy kết quả khác nhau để so sánh những nhân vật tương tự, tùy thuộc vào kiểu dữ liệu nằm bên dưới. Ví dụ, nếu bạn đang sử dụng SQL collation "SQL_Latin1_General_CP1_CI_AS", Phi-Unicode chuỗi 'a-c' là ít hơn hơn chuỗi 'ab' bởi vì gạch nối ("-") được sắp xếp theo một nhân vật riêng biệt mà đến trước khi "b". Tuy nhiên, nếu bạn chuyển đổi các dây Unicode và bạn thực hiện các so sánh tương tự, chuỗi Unicode N'a-c' được coi là lớn hơn N'ab' vì Unicode phân loại quy định sử dụng một loại từ"" mà bỏ qua dấu nối.

Chuỗi so sánh hiệu suất

Unicode phân loại quy tắc là phức tạp hơn so với các quy tắc cho một Thứ tự sắp xếp Phi - Unicode SQL. Khi SQL Server so sánh dữ liệu Unicode, các ký tự được chỉ định một trọng lượng tự động thay đổi dựa trên các collation của miền địa phương. Dữ liệu cũng lần bằng cách so sánh cài đặt kiểu như vậy như chiều rộng, giọng hay Kana nhạy cảm. Thói quen sắp xếp Unicode hỗ trợ hơn sắp xếp thông minh hành vi như từ phân loại.

Ngoài ra, bởi vì các thói quen phải xử lý dữ liệu Unicode, họ là linh hoạt, đủ để xử lý các phân loại và so sánh của một vài nghìn nhân vật khác biệt, thay vì của tối đa 255 ký tự mà nhất SQL Server loại đơn đặt hàng có thể xử lý. Vì những lý do, nguyên chuỗi so sánh công việc sử dụng Unicode phân loại quy tắc là thường đắt hơn trong điều kiện thời gian và CPU chu kỳ hơn một so sánh tương tự chuỗi có sử dụng một Thứ tự sắp xếp Phi - Unicode SQL.

Điều này có nghĩa cho là có thể tổ hợp các loại dữ liệu và collation loại trong SQL Server:
  • Nếu bạn đang lưu trữ và xử lý dữ liệu của bạn bằng cách sử dụng các loại dữ liệu không dùng Unicode)Char, varchar, văn bản), và bạn đang sử dụng một collation SQL, so sánh chuỗi sẽ thực hiện với một thứ tự sắp xếp Phi - Unicode SQL.
  • Nếu bạn đang lưu trữ và xử lý dữ liệu của bạn bằng cách sử dụng các loại dữ liệu không dùng Unicode)Char, varchar, văn bản), và bạn đang sử dụng một Windows collation, so sánh chuỗi sẽ được thực hiện với Unicode phân loại quy tắc. Điều này có thể gây ra một số hoạt động kinh doanh đó là bất thường phụ thuộc vào chuỗi phân loại hiệu suất để kéo dài lâu hơn và sử dụng CPU nhiều hơn một hoạt động tương tự được thực hiện với một SQL collation.
  • Nếu bạn đang sử dụng Unicode dữ liệu các loại)NCHAR, nvarchar, ntext), không có sự khác biệt trong hành vi phân loại cho SQL và Windows collations. Cả hai sẽ sử dụng Unicode phân loại quy tắc.
Nói chung, mức độ của sự khác biệt hiệu suất giữa các Windows và SQL collations sẽ không đáng kể. Sự khác biệt chỉ xuất hiện nếu một khối lượng công việc là bị ràng buộc CPU, chứ không phải bị hạn chế bởi I/O hoặc bởi tốc độ mạng, và hầu hết trong số này CPU gánh nặng gây ra bởi các trên cao của thao tác chuỗi hoặc so sánh thực hiện trong SQL Server. Một Ví dụ về một ứng dụng, nơi mà sự khác biệt hiệu suất có thể được phát âm là một hệ thống nơi mà một ứng dụng đi một giá trị chuỗi dài đến một máy chủ SQL thủ tục được lưu trữ. Các thủ tục được lưu trữ sau đó phân tích chuỗi thông qua mở rộng sử dụng chức năng thao tác chuỗi Transact-SQL như CHARINDEX hoặc PATINDEX. Nếu khối lượng công việc khá one-dimensional và nó bị chi phối bởi xử tử của chuỗi này phân tích cú pháp thủ tục được lưu trữ, sự khác biệt hiệu suất giữa một SQL collation và Windows collation có thể là đáng chú ý. Tuy nhiên, thiết kế hầu hết các ứng dụng không dẫn đến một tình hình nơi hiệu suất sự khác biệt là đáng kể.

Khuyến nghị

  1. SQL collations được cung cấp cho tương thích ngược với Phiên bản trước của SQL Server. Windows collations cung cấp nhất quán chuỗi so sánh cả hai Unicode và cho văn bản không dùng Unicode trong SQL Server đang cũng phù hợp với chuỗi so sánh trong hệ điều hành Windows. Cho tất cả những lý do này, Windows collations được ưa thích trừ khi có rất lạc hậu vấn đề tương thích hoặc các vấn đề hiệu suất cụ thể yêu cầu một SQL collation.
  2. Nếu bạn đang xem xét một collation SQL dựa chỉ trên các hiệu suất đặc tính của một collation SQL, nhận ra rằng các hiệu suất của hầu hết các ứng dụng không có lợi cho một cách đáng kể từ một sự thay đổi trong collation. Hãy chắc chắn rằng bạn đã cô lập truy vấn hiển thị một lợi ích từ SQL collation. Ngay sau khi bạn xác định các truy vấn bị ảnh hưởng, xem xét các lựa chọn thay thế sau đây để thay đổi về collation. Cả hai của những lựa chọn thay thế có thể cung cấp một hiệu suất lợi ích lớn hơn những gì bạn sẽ thấy nếu bạn thay đổi collation thẩm để một collation SQL:
    1. Nếu chi phí cho Windows collations nguồn từ Thói quen SQL giao dịch thực hiện thao tác chuỗi rõ ràng hoặc phân tích, và nếu bạn đang sử dụng các loại dữ liệu không dùng Unicode, bạn có thể chỉ định một collation SQL hoặc một nhị phân Windows collation cho các hoạt động mà thường xuyên bị hành quyết và đó là đắt nhất. Giả sử bạn sử dụng chức năng PATINDEX để xác định liệu một văn bản cột trong một bảng chứa các ký tự "x". Nếu bạn buộc một collation SQL để mà so sánh đặc biệt hoạt động, và bạn tiếp tục sử dụng một cửa sổ collation cho phần còn lại của cơ sở dữ liệu và các ứng dụng, bạn không cần phải thay đổi collation cho toàn bộ hệ thống:
      SELECT PATINDEX ('%x%', MemoFld COLLATE SQL_Latin1_General_Cp1_CI_AS) FROM ...
    2. Nếu chi phí cho Windows collations nguồn từ thêm trần tục truy vấn nào không sử dụng chuỗi phức tạp thao tác chức năng, cải tiến thiết kế chỉ số hoặc truy vấn có thể cung cấp cải tiến mà lùn những người bạn sẽ thấy bằng cách thay đổi một collation SQL. Một truy vấn có thể hài lòng bởi tìm kiếm rất chọn lọc về chỉ số thích hợp sẽ không được nhạy cảm với tiểu những thay đổi trong chuỗi so sánh chi phí. Ngược lại, một số lượng nhỏ của chi phí cho mỗi so sánh chuỗi có thể thêm lên nhanh chóng trong một truy vấn phải thực hiện một bảng quét và so sánh một giá trị cụ thể cho mỗi hàng triệu hàng. Nếu bạn ngăn chặn bảng lớn hoặc chỉ số quét từ kế hoạch truy vấn bằng cách thay đổi các chỉ mục hoặc các truy vấn riêng của mình, truy vấn của bạn sẽ thực hiện nhanh hơn nhiều hơn nó nếu bạn thay đổi để một collation SQL.
Chú ý Đó là một loại thứ ba của collation là một biến thể của một SQL collation. Collation thứ ba này được gọi là một "khả năng tương thích collation" hoặc một "chiếc collation." Một khả năng tương thích collation là một tập hợp các phân loại và so sánh quy tắc mà không có một tên được xác định trước collation trong SQL Server 2000. Ví dụ, nếu bạn đã thiết lập SQL Server 7.0 với một không phù hợp Case-sensitivity cài đặt Unicode và dữ liệu không dùng Unicode, bạn sẽ có một khả năng tương thích collation khi bạn nâng cấp này thể hiện của SQL Server 7.0 với SQL Server 2000. Trong các cuộc thảo luận trước đó trong bài viết này, các thông tin về SQL collations cũng áp dụng cho khả năng tương thích collations.

Để biết thêm thông tin về khả năng tương thích collations, nhấp vào số bài viết sau đây để xem bài viết trong cơ sở kiến thức Microsoft:
270042INF: Mô tả của SQL Server khả năng tương thích collations
chậm perf

Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 322112 - Xem lại Lần cuối: 08/27/2011 12:39:00 - Bản sửa đổi: 2.0

Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition

  • kbhowto kbinfo kbmt KB322112 KbMtvi
Phản hồi