Speicherung und Leistungsauswirkungen von Unicode
SQL Server speichert Unicode-Daten mit dem UCS-2-Codierschema.Mit diesem Mechanismus werden alle Unicode-Zeichen mithilfe von 2 Byte gespeichert.
Die Unterschiede zwischen Unicode und Nicht-Unicode beim Speichern von Zeichendaten hängen davon ab, ob die Nicht-Unicode-Daten mithilfe von Doppelbyte-Zeichensätzen gespeichert wurden. Alle nichtasiatischen Sprachen und Thai speichern Nicht-Unicode-Zeichen als Einzelbytes. Aus diesem Grund ist für das Speichern dieser Sprachen als Unicode doppelt so viel Speicherplatz wie bei Angabe einer Nicht-Unicode-Codepage erforderlich. Einerseits geben die Nicht-Unicode-Codepages zahlreicher anderer asiatischer Sprachen die Zeichenspeicherung in Doppelbyte-Zeichensätzen (Double-Byte Character Set, DBCS) an. Für diese Sprachen besteht daher fast kein Unterschied zwischen der Speicherung als Nicht-Unicode und Unicode.
Die folgende Tabelle zeigt die Nicht-Unicode-Codepages, die Zeichendatenspeicherung in Doppelbyte-Zeichensätzen angeben.
Sprache |
Codepage |
|---|---|
Chinesisch (vereinfacht) |
936 |
Chinesisch (traditionell) |
950 |
Japanisch |
932 |
Koreanisch |
949 |
Die Auswirkungen von Unicode-Daten auf die Leistung werden durch eine Vielzahl von Faktoren wie z. B. die folgenden beeinflusst:
den Unterschied zwischen Unicode-Sortierregeln und Nicht-Unicode-Sortierregeln;
den Unterschied zwischen dem Sortieren von Doppelbyte- und Einzelbytezeichen;
die Codepagekonvertierung zwischen Client und Server.
SQL Server führt Zeichenfolgevergleiche der Nicht-Unicode-Daten, die mit einer Windows-Sortierung definiert wurden, mit Unicode-Sortierregeln aus. Da diese Regeln wesentlich komplexer als Nicht-Unicode-Sortierregeln sind, sind sie ressourcenintensiver. Obwohl Unicode-Sortierregeln häufig ressourcenintensiver sind, besteht im Allgemeinen nur ein geringer Unterschied hinsichtlich der Leistung zwischen Unicode-Daten und Nicht-Unicode-Daten, die mit einer Windows-Sortierung definiert wurden.
Der einzige Fall, in dem SQL Server Nicht-Unicode-Sortierregeln verwendet, tritt bei Nicht-Unicode-Daten ein, die mit SQL-Sortierung definiert wurden. Sortierungen und Scans sind in diesem Fall im Allgemeinen schneller als bei Anwendung von Unicode-Sortierregeln. Unicode-Sortierregeln gelten für alle Unicode-Daten, die mit einer Windows- oder SQL-Sortierung definiert wurden.
Weniger gravierend ist, dass das Sortieren einer großen Menge von Unicode-Daten langsamer als bei Nicht-Unicode-Daten sein kann, weil die Daten als Doppelbytezeichen gespeichert werden. Andererseits ist das Sortieren asiatischer Zeichen schneller als das Sortieren asiatischer DBCS-Daten in einer bestimmten Codepage, weil DBCS-Daten eine Mischung aus Einzelbyte- und Doppelbytezeichen darstellen, während Unicode-Zeichen eine feste Breite aufweisen.
Weitere Leistungseinbußen ergeben sich hauptsächlich aus dem Konvertieren des Codierungsmechanismus zwischen einer Instanz von SQL Server und dem Client. Im Allgemeinen sind die Auswirkungen auf die Leistung durch die Konvertierung der Client/Servercodepage zu vernachlässigen. Sie sollten dennoch verstanden haben, was in dieser Schicht passiert.
Die ODBC-API, Version 3.6 oder früher, und die DB-Library-API erkennen Unicode nicht. Für Clients, die Datenzugriffsmethoden verwenden, die durch diese APIs definiert werden, werden Ressourcen zum impliziten Konvertieren von Unicode-Daten in die Clientcodepage verwendet. Außerdem besteht ein Risiko, dass die Daten auf der Clientseite beschädigt werden, wenn die Clientcodepage bestimmte Unicode-Zeichen nicht erkennt.
Spätere Versionen von ODBC ab Microsoft Data Access Components (MDAC), Version 2.7, die im Lieferumfang von SQL Server, Version 7.0, enthalten waren, sowie OLE DB und ADO erkennen Unicode und gehen von einem UCS-2-Codierungsmechanismus aus. Wenn die Anwendung für Unicode aktiviert ist, bestehen daher keine Konvertierungsprobleme, wenn Sie strikt mit Unicode-Daten aus einer Instanz von SQL Server arbeiten. Wenn ein Client eine Unicode-aktivierte API verwendet, deren Datenspeichermechanismus in der Instanz von SQL Server jedoch nicht Unicode ist, treten keine Konvertierungsprobleme auf. Es besteht jedoch das Risiko, dass Daten bei Einfüge- oder Aktualisierungsvorgänge beschädigt werden, wenn die Codepunkte für eines der Zeichen nicht der SQL Server-Codepage zugeordnet werden können.
Bewährte Methoden bezüglich Unicode
Die Entscheidung, ob Nicht-DBCS-Daten als Unicode gespeichert werden sollen, wird im Allgemeinen basierend auf dem Wissen um die Auswirkungen auf die Speicherung gefällt. Außerdem spielt das Ausmaß der Sortierung, Konvertierung und möglichen Datenbeschädigung während der Clientinteraktionen mit den Daten eine Rolle. Sortierung und Konvertierung können sich abhängig davon, wo sie auftreten, auf die Leistung auswirken. Für die meisten Anwendungen sind diese Auswirkungen jedoch zu vernachlässigen. Bei Datenbanken mit sorgfältig geplanten Indizes ist es besonders unwahrscheinlich, dass sie betroffen sind. Eine Datenbeschädigung wirkt sich jedoch nicht nur auf die Integrität einer Anwendung bzw. Datenbank aus, sondern auch auf das Unternehmen als Ganzes. Unter Berücksichtigung dieses Nachteils kann das Speichern von Zeichendaten in einer bestimmten Codepage sinnvoll sein, wenn die beiden folgenden Aspekte zutreffen:
Aufgrund von Hardwareeinschränkungen soll Speicherplatz gespart werden. Oder Sie sortieren häufig große Mengen von Daten, und Tests haben ergeben, dass ein Unicode-Speichermechanismus die Leistung erheblich beeinträchtigt.
Sie sind sicher, dass die Codepages aller Clients, die auf diese Daten zugreifen, Ihren Codepages entsprechen und dass sich dies nicht unerwartet ändert.
In den meisten Fällen sollte die Entscheidung, Zeichendaten (selbst Nicht-DBCS-Daten) in Unicode zu speichern, schwerpunktmäßig auf den Anforderungen des Unternehmens und nicht auf der Leistung basieren. In einer globalen Wirtschaft, die durch ein schnelles Wachstum des Internetdatenverkehrs befördert wird, wird es zu einer wesentlichen Aufgabe, Clientcomputer zu unterstützen, die andere Gebietsschemas ausführen. Außerdem wird es zunehmend schwieriger, eine einzelne Codepage auszuwählen, die alle Zeichen unterstützt, die von einem weltweiten Publikum benötigt werden.