collations การเปรียบเทียบของ SQL เพื่อ Windows collations

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 322112 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

สรุป

ใน Microsoft SQL Server 2000 และ Microsoft SQL Server 2005 เปรียบเป็น "เทียบ" ระบุวิธีการเปรียบเทียบสตริงการ และเรียงลำดับ และอักขระใดมีใช้ชุดข้อมูลที่ไม่ใช่ Unicode sql Server 2000 สนับสนุน collations สองชนิด:
  • sql collations
  • windows collations
สำหรับคำอธิบายของแต่ละชนิดของการเปรียบเทียบและภาพรวมวิธีการตัดสินใจที่เปรียบเทียบการใช้ทางดี ดูหัวข้อ "Collations ที่เลือก" ใน SQL Server 2000 หนังสือออนไลน์ หรือดูหัวข้อ "เปรียบเทียบชนิด" ใน SQL Server 2005 หนังสือออนไลน์

บทความนี้กล่าวถึงข้อควรพิจารณาเพิ่มเติมที่อาจส่งผลต่อการตัดสินใจของคุณเกี่ยวกับว่าจะเลือกการเปรียบเทียบ Windows หรือการเปรียบเทียบของ SQL เมื่อคุณติดตั้ง SQL Server 2000 หรือ SQL Server 2005

ข้อมูลเพิ่มเติม

เปรียบเทียบหมาย

สำหรับการเปรียบเทียบ Windows การเปรียบเทียบข้อมูลไม่ใช่ Unicode ถูกนำมาใช้ โดยใช้อัลกอริทึมที่เหมือนกันเป็นข้อมูล Unicode ทั้ง Unicode และการเรียงลำดับไม่ใช่ Unicode เข้ากันได้กับกฎการเปรียบเทียบสายอักขระใน Windows รุ่นที่เฉพาะ ซึ่งให้เกิดความสม่ำเสมอระหว่างชนิดข้อมูลใน SQL Server นอกจากนี้ยังช่วยนักพัฒนาที่ใช้ในCompareStringฟังก์ชัน win32 API เพื่อเรียงลำดับสตริงการในโปรแกรมประยุกต์ของตนเอง โดยใช้กฎเดียวกับที่ใช้ SQL Server

ในการเปรียบเทียบ SQL, SQL Server กำหนดหมายเปรียบเทียบที่แตกต่างกันสำหรับข้อมูลที่ไม่ใช่ Unicode sql Server bases หมายเหล่านี้เปรียบเทียบบน SQL "เรียงลำดับ" สำหรับการแมปของใบสั่งการเรียงลำดับเพื่อ SQL collations ให้ดูที่หัวข้อ "ชื่อการเปรียบเทียบของ SQL" ใน SQL Server หนังสือออนไลน์

กฎของเปรียบเทียบกับ SQL สำหรับการเรียงลำดับข้อมูลที่ไม่ใช่ Unicode เข้ากันกับชุดคำสั่งใด ๆ เรียงลำดับที่ให้ไว้ โดย Microsoft Windows ทำงานระบบ การอย่างไรก็ตาม เรียงลำดับข้อมูล Unicode ไม่เข้ากันได้กับกฎการเรียงลำดับของ Windows รุ่นที่เฉพาะ เนื่องจากกฎการเปรียบเทียบสำหรับใช่ Unicode และข้อมูล Unicode แตกต่างกัน เมื่อคุณใช้การเปรียบเทียบของ SQL คุณอาจเห็นผลลัพธ์ที่แตกต่างกันสำหรับ comparisons อักขระเดียวกัน ขึ้นอยู่กับชนิดข้อมูลแบบพื้นฐาน ตัวอย่าง หากคุณใช้ SQL เปรียบเทียบ "SQL_Latin1_General_CP1_CI_AS" 'ใด c' ของสายอักขระที่ไม่ใช่ Unicode จะน้อยกว่าสายอักขระ 'ab' ได้เนื่องจากยัติภังค์ ("-") จะเรียงลำดับตามอักขระที่แยกต่างหากที่มาก่อน "b" อย่างไรก็ตาม ถ้าคุณแปลงสตริงการเหล่านี้ไปยัง Unicode และคุณทำการเปรียบเทียบเดียวกัน สายอักขระ Unicode N'a c 'จะถือเป็นมากกว่า N'ab' ได้เนื่องจากการเรียงลำดับ Unicode กฎใช้กับ "คำเรียง" ที่ละเว้นยัติภังค์

สายอักขระการเปรียบเทียบประสิทธิภาพ

กฎการเรียงลำดับ unicode ที่ซับซ้อนมากยิ่งขึ้นกว่ากฎสำหรับการเรียงลำดับที่ไม่ใช่ - Unicode SQL ได้ เมื่อข้อมูล Unicode ที่เปรียบเทียบของ SQL Server อักขระที่ถูกกำหนดเป็นน้ำหนักที่ถูกปรับเปลี่ยนแบบไดนามิกขึ้นอยู่กับตำแหน่งที่ตั้งของเปรียบเทียบ ข้อมูลจะยัง comparison โดยการตั้งค่าลักษณะเช่นความกว้าง เน้น หรือระดับความ ลับคะนะปรับเปลี่ยนแล้ว ตามปกติการเรียงลำดับ Unicode สนับสนุนการเรียงลำดับมากพอร์ที่ทำงานเหมือนกับการเรียงลำดับของคำ

นอกจากนี้ เนื่องจากตามปกติจะต้องจัดการข้อมูล Unicode มียืดหยุ่นเพียงพอในการจัดการเรียงลำดับและเปรียบเทียบของหลาย thousand แตกต่างอักขระ แทนสูงสุด 255 อักขระที่ใบสั่งการเรียงลำดับของ sql server ส่วนใหญ่สามารถจัดการ ด้วยเหตุนี้ ทำการเปรียบเทียบสตริงที่ raw ที่ใช้ Unicode กฎการเรียงลำดับอยู่โดยทั่วไปยิ่งแพงเงื่อนไขของเวลาและรอบ CPU เปรียบเทียบสายอักขระที่คล้ายกันที่ใช้เรียงลำดับที่ไม่ใช่ - Unicode SQL ที่ไม่ใช่

สิ่งนี้หมายความสำหรับชุดที่เป็นไปได้ของชนิดข้อมูลและชนิดเปรียบเทียบใน SQL Server:
  • ถ้าคุณกำลัง จัดเก็บ และการจัดการข้อมูลของคุณ โดยใช้ข้อมูลที่ไม่ใช่ Unicode ชนิด(Char:,varchar,ข้อความ), และคุณกำลังใช้การเปรียบเทียบของ SQL, comparisons สายอักขระที่จะกระทำกับลำดับการเรียงลำดับไม่ - Unicode SQL
  • ถ้าคุณกำลัง จัดเก็บ และการจัดการข้อมูลของคุณ โดยใช้ข้อมูลที่ไม่ใช่ Unicode ชนิด(Char:,varchar,ข้อความ), และคุณกำลังใช้การเปรียบเทียบ Windows, comparisons สายอักขระที่จะกระทำกับ Unicode กฎการเรียงลำดับ ซึ่งอาจทำให้การดำเนินการบางอย่างที่ผิดปกติขึ้นสายอักขระที่เรียงลำดับประสิทธิภาพการทำงาน เพื่อที่ใช้เวลานาน และใช้ CPU ที่มีการเพิ่มเติมนอกเหนือจากการดำเนินงานที่คล้ายกันที่จะดำเนินการกับ SQL เปรียบเทียบกัน
  • ถ้าคุณกำลังใช้ Unicode (ชนิดของข้อมูลnchar,nvarchar,ntext), ไม่มีความแตกต่างในลักษณะการทำงานเรียงลำดับสำหรับ SQL และ Windows collations Both will use Unicode sorting rules.
Generally, the degree of performance difference between the Windows and the SQL collations will not be significant. The difference only appears if a workload is CPU-bound, rather than being constrained by I/O or by network speed, and most of this CPU burden is caused by the overhead of string manipulation or comparisons performed in SQL Server. An example of an application where the performance difference might be pronounced is a system where an application passes a long string value to a SQL Server stored procedure. The stored procedure then parses the string through extensive use of Transact-SQL string manipulation functions like CHARINDEX or PATINDEX. If the workload is fairly one-dimensional and it is dominated by executions of this string parsing stored procedure, the difference in performance between a SQL collation and a Windows collation might be noticeable. However, the design of most applications does not lead to a situation where the performance difference is significant.

Recommendations

  1. SQL collations are provided for backward compatibility with earlier versions of SQL Server. Windows collations provide consistent string comparisons for both Unicode and for non-Unicode text in SQL Server that are also consistent with string comparisons in the Windows operating system. For all these reasons, Windows collations are preferred unless there are backward compatibility issues or specific performance issues that require a SQL collation.
  2. If you are considering a SQL collation based only on the performance characteristics of a SQL collation, realize that the performance of most applications does not benefit significantly from a change in collation. Make sure that you have isolated queries that show a benefit from a SQL collation. As soon as you identify the affected queries, consider the following alternatives to a change in collation. Both of these alternatives may provide a performance benefit that is greater than what you will see if you change the instance collation to a SQL collation:
    1. If the overhead for the Windows collations is traced to Transact-SQL routines that perform explicit string manipulation or parsing, and if you are using non-Unicode data types, you may want to specify a SQL collation or a binary Windows collation for the operation that is frequently executed and that is most expensive. Suppose you use the PATINDEX function to determine whether a text column in a table contains the "x" character. If you force a SQL collation for that particular comparison operation, and you continue to use a Windows collation for the rest of the database and the application, you do not have to change the collation for the whole system:
      SELECT PATINDEX ('%x%', MemoFld COLLATE SQL_Latin1_General_Cp1_CI_AS) FROM ...
    2. If the overhead for the Windows collations is traced to more mundane queries that do not use complex string manipulation functions, improved index or query designs might provide improvements that dwarf those you would see by changing to a SQL collation. A query that can be satisfied by highly selective seeks on appropriate indexes will not be sensitive to minor changes in string comparison cost. In contrast, a small amount of overhead per string comparison can add up quickly in a query that must perform a table scan and compare a particular value to each of millions of rows. If you prevent large table or index scans from the query plan by changing the indexing or the query itself, your query will perform much faster than it would if you change to a SQL collation.
หมายเหตุ:There is a third type of collation that is a variation of a SQL collation. This third collation is known as a "compatibility collation" or an "obsolescent collation." A compatibility collation is a set of sorting and comparison rules that do not have a predefined collation name in SQL Server 2000. For example, if you set up SQL Server 7.0 with an inconsistent case-sensitivity setting for Unicode and for non-Unicode data, you will have a compatibility collation when you upgrade this instance of SQL Server 7.0 to SQL Server 2000. In the discussion earlier in this article, the information about SQL collations also applies to compatibility collations.

For more information about compatibility collations, click the following article number to view the article in the Microsoft Knowledge Base:
270042INF: Description of SQL Server compatibility collations

คุณสมบัติ

หมายเลขบทความ (Article ID): 322112 - รีวิวครั้งสุดท้าย: 13 มกราคม 2554 - Revision: 4.0
ใช้กับ
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
Keywords: 
kbhowto kbinfo kbmt KB322112 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:322112

ให้ข้อเสนอแนะ

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com