Không giống như một số RDBMS khác cho phép chọn một kiểu mã hóa, SQL Server lưu trữ dữ liệu Unicode chỉ trong UTF-16 (Little Endian) và dữ liệu không phải Unicode ở dạng mã hóa 8 bit (Extended ASCII, DBCS hoặc EBCDIC) cho bất kỳ Trang mã nào được ngụ ý bởi Đối chiếu của trường.
Quyết định của họ để chọn UCS-2 có đủ ý nghĩa vì UTF-16 đã được giới thiệu vào giữa năm 1996 và được chỉ định đầy đủ vào năm 2000. Rất nhiều hệ thống khác cũng sử dụng (hoặc đã sử dụng) nó (vui lòng xem: https://en.wikipedia.org/wiki/UTF-16#Usage ). Quyết định của họ là tiếp tục với nó có thể có nhiều nghi vấn hơn, mặc dù có thể là do Windows và .NET là UTF-16. Bố cục vật lý của các byte giống nhau giữa UCS-2 và UTF-16, vì vậy việc nâng cấp hệ thống từ UCS-2 để hỗ trợ UTF-16 phải hoàn toàn hoạt động mà không cần phải thay đổi bất kỳ dữ liệu hiện có nào.
À, không. Tạo Loại tùy chỉnh do người dùng xác định thông qua SQLCLR là không , theo bất kỳ cách nào, sẽ giúp bạn thay thế bất kỳ loại bản địa nào. Nó rất tiện dụng để tạo thứ gì đó để xử lý dữ liệu chuyên dụng. Nhưng các chuỗi, thậm chí thuộc một bảng mã khác, không chuyên biệt. Đi theo lộ trình này cho dữ liệu chuỗi của bạn sẽ phá hủy mọi khả năng sử dụng của hệ thống, chưa kể đến hiệu suất vì bạn sẽ không thể sử dụng bất kỳ các hàm chuỗi tích hợp sẵn. Nếu bạn có thể lưu bất cứ thứ gì trên dung lượng ổ đĩa, những lợi ích đó sẽ bị xóa bởi những gì bạn sẽ mất trong hiệu suất tổng thể. Việc lưu trữ một UDT được thực hiện bằng cách tuần tự hóa nó thành một VARBINARY . Vì vậy, để làm bất kỳ so sánh chuỗi HOẶC sắp xếp, bên ngoài so sánh "nhị phân" / "thứ tự", bạn sẽ phải chuyển đổi tất cả các giá trị khác, từng giá trị một, trở lại UTF-8 để sau đó thực hiện so sánh chuỗi có thể giải thích sự khác biệt về ngôn ngữ.
Ngoài ra, "tài liệu" đó thực sự chỉ là mã mẫu / bằng chứng về nội dung khái niệm. Mã được viết vào năm 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) cho SQL Server 2005. Tôi đã thấy một tập lệnh để kiểm tra chức năng, nhưng không có gì liên quan đến hiệu suất.
Vâng, rất nhiều như vậy. Theo mặc định, việc xử lý các chức năng tích hợp chỉ dành cho UCS-2. Nhưng bắt đầu từ SQL Server 2012, bạn có thể yêu cầu chúng xử lý bộ ký tự UTF-16 đầy đủ (cũng như Unicode Phiên bản 5 hoặc 6, tùy thuộc vào hệ điều hành và phiên bản .NET Framework của bạn) bằng cách sử dụng một trong các đối chiếu có tên kết thúc bằng _SC (tức là các nhân vật bổ sung).
Chính xác. UTF-16 và UCS-2 đều sử dụng điểm mã 2 byte. Nhưng UTF-16 sử dụng một số trong số chúng theo cặp (tức là Cặp thay thế) để ánh xạ các ký tự bổ sung. Các điểm mã được sử dụng cho các cặp này được dành riêng cho mục đích này trong UCS-2 và do đó không được sử dụng để ánh xạ tới bất kỳ ký hiệu có thể sử dụng nào. Đây là lý do tại sao bạn có thể lưu trữ bất kỳ ký tự Unicode nào trong SQL Server và nó sẽ được lưu trữ và truy xuất một cách chính xác.
Đúng, mặc dù sai. Có, UTF-8 có chiều rộng thay đổi, nhưng UTF-16 cũng có thể thay đổi nhỏ vì tất cả các Ký tự bổ sung đều bao gồm hai điểm mã byte kép. Do đó UTF-16 sử dụng 2 hoặc 4 byte cho mỗi biểu tượng, mặc dù UCS-2 luôn là 2 byte. Nhưng đó không phải là phần gây hiểu lầm. Điều gây hiểu lầm là ngụ ý rằng bất kỳ bảng mã Unicode nào khác không có khả năng mã hóa tất cả các điểm mã khác. Mặc dù UCS-2 có thể giữ chúng nhưng không giải thích chúng, cả UTF-16 và UTF-32 đều có thể ánh xạ tất cả các điểm mã Unicode, giống như UTF-8.
Điều này có thể đúng, nhưng nó hoàn toàn không liên quan từ góc độ hoạt động.
Một lần nữa, đúng, nhưng hoàn toàn không liên quan vì UTF-16 và UTF-32 cũng ánh xạ tất cả các điểm mã Unicode.
Tùy thuộc vào hoàn cảnh, điều này rất có thể đúng, và bạn đúng khi lo lắng về việc sử dụng lãng phí như vậy. Tuy nhiên, như tôi đã đề cập trong câu hỏi dẫn đến câu hỏi này ( Hỗ trợ UTF-8, SQL Server 2012 và UTF8String UDT
), bạn có một số tùy chọn để giảm thiểu lượng không gian bị lãng phí nếu hầu hết các hàng có thể vừa với VARCHAR nhưng một số cần phải là NVARCHAR . Tùy chọn tốt nhất là bật NÉN ROW hoặc NÉN TRANG (chỉ dành cho Enterprise Editon!). Bắt đầu từ SQL Server 2008 R2, chúng cho phép NVARCHAR không phải MAX các trường sử dụng "Lược đồ nén chuẩn cho Unicode" ít nhất cũng tốt như UTF-8 và trong một số trường hợp, nó thậm chí còn tốt hơn UTF-8. NVARCHAR(MAX) các trường không thể sử dụng tính năng nén ưa thích này , nhưng dữ liệu IN ROW của họ có thể được hưởng lợi từ ROW và / hoặc Nén PAGE thông thường. Vui lòng xem phần sau để biết mô tả về tính năng nén này và biểu đồ so sánh kích thước dữ liệu cho:raw UCS-2 / UTF-16, UTF-8 và UCS-2 / UTF-16 có bật tính năng nén dữ liệu.
SQL Server 2008 R2 - Nén UCS2 là gì - Ảnh hưởng đến hệ thống SAP
Vui lòng xem trang MSDN để biết Nén dữ liệu để biết thêm chi tiết vì có một số hạn chế (ngoài ra nó chỉ có sẵn trong Phiên bản Doanh nghiệp - NHƯNG được cung cấp cho tất cả các phiên bản bắt đầu với SQL Server 2016, SP1 !!) và một số trường hợp khi nén có thể làm mọi thứ tồi tệ hơn.
Tính xác thực của tuyên bố đó phụ thuộc vào cách người ta định nghĩa "đĩa". Nếu bạn đang nói về các bộ phận hàng hóa mà bạn có thể mua ngoài kệ tại một cửa hàng để sử dụng cho máy tính để bàn / máy tính xách tay của mình, thì hãy chắc chắn. Tuy nhiên, nếu nói về bộ nhớ cấp doanh nghiệp sẽ được sử dụng cho hệ thống Sản xuất của bạn, thì hãy giải thích vui vẻ cho bất kỳ ai kiểm soát ngân sách rằng họ không nên từ chối SAN hàng triệu đô la mà bạn muốn vì nó "rẻ ";-).
Không có gì mà tôi có thể nghĩ ra. Chà, miễn là bạn không làm theo bất kỳ lời khuyên khủng khiếp nào để làm điều gì đó như triển khai UDT đó hoặc chuyển đổi tất cả các chuỗi thành VARBINARY hoặc sử dụng NVARCHAR(MAX) cho tất cả các trường chuỗi;-). Nhưng trong số tất cả những điều bạn có thể lo lắng, SQL Server sử dụng UCS-2 / UTF-16 không nên là một trong số đó.
Tuy nhiên, nếu vì lý do nào đó, vấn đề không hỗ trợ gốc cho UTF-8 này là cực kỳ quan trọng, thì bạn có thể cần phải tìm một RDBMS khác để sử dụng mà không cho phép UTF-8.
CẬP NHẬT 2018-10-02
Mặc dù đây chưa phải là một tùy chọn khả thi, nhưng SQL Server 2019 giới thiệu hỗ trợ gốc cho UTF-8 trong VARCHAR / CHAR Loại dữ liệu. Hiện có quá nhiều lỗi để nó được sử dụng, nhưng nếu chúng được sửa thì đây là một tùy chọn cho một số các tình huống. Vui lòng xem bài đăng của tôi, " Hỗ trợ UTF-8 gốc trong SQL Server 2019:Vị cứu tinh hay nhà tiên tri sai?
", để phân tích chi tiết về tính năng mới này.
