27 Stimmen

Was sind die Unterschiede zwischen CHECKSUM() und BINARY_CHECKSUM() und wann/wofür sind die geeigneten Nutzungsszenarien?

MSDN erklärt nicht wirklich in verständlichem Englisch den genauen Unterschied oder die Informationen, wann man das eine oder das andere wählen sollte.

CHECKSUM

Gibt den Prüfsummenwert zurück, der über eine Zeile einer Tabelle oder über eine Liste von Ausdrücken berechnet wurde. CHECKSUM ist zur Verwendung beim Erstellen von Hash-Indizes gedacht.

BINARY_CHECKSUM

Gibt den binären Prüfsummenwert zurück, der über eine Zeile einer Tabelle oder über eine Liste von Ausdrücken berechnet wurde. BINARY_CHECKSUM kann verwendet werden, um Änderungen an einer Zeile einer Tabelle zu erkennen.

Es wird angedeutet, dass die binäre Prüfsumme verwendet werden sollte, um Änderungen an Zeilen zu erkennen, aber nicht warum.

24voto

John Sansom Punkte 40295

Überprüfen Sie den folgenden Blog-Beitrag, der die Unterschiede hervorhebt.

http://decipherinfosys.wordpress.com/2007/05/18/checksum-functions-in-sql-server-2005/

Hinzufügen von Informationen aus diesem Link:

Der Hauptzweck der CHECKSUM-Funktionen besteht darin, einen Hash-Index basierend auf einem Ausdruck oder einer Spaltenliste zu erstellen. Wenn Sie es beispielsweise verwenden, um eine Spalte auf Tabellenebene zu berechnen und zu speichern, um den Prüfsummenwert über die Spalten zu bezeichnen, die einen Datensatz in einer Tabelle eindeutig machen, kann dies nützlich sein, um festzustellen, ob sich ein Datensatz geändert hat oder nicht. Dieser Mechanismus kann dann anstelle eines Joins mit allen Spalten, die den Datensatz eindeutig machen, verwendet werden, um festzustellen, ob der Datensatz aktualisiert wurde oder nicht. Das SQL Server Books Online enthält viele Beispiele für dieses Funktionsstück.

Ein paar Dinge, auf die Sie achten sollten, wenn Sie diese Funktionen verwenden:

Sie müssen sicherstellen, dass die Reihenfolge der Spalten oder Ausdrücke zwischen den beiden Prüfsummen gleich ist, die verglichen werden, sonst wäre der Wert unterschiedlich und würde zu Problemen führen.

Wir würden nicht empfehlen, checksum(*) zu verwenden, da der auf diese Weise generierte Wert auf der Spaltenreihenfolge der Tabellendefinition zur Laufzeit basiert, was sich im Laufe der Zeit leicht ändern kann. Definieren Sie also explizit die Spaltenliste.

Achten Sie darauf, wann Sie die Spalten vom Typ datetime einschließen, da die Granularität 1/300 Sekunde beträgt und selbst eine kleine Abweichung zu einem anderen Prüfsummenwert führt. Wenn Sie also eine Spalte vom Typ datetime verwenden müssen, stellen Sie sicher, dass Sie das genaue Datum + Stunde/Minute erhalten. d.h. die Granularitätsebene, die Sie möchten.

Ihnen stehen drei Prüfsummenfunktionen zur Verfügung:

CHECKSUM: Dies wurde oben beschrieben.

CHECKSUM_AGG: Dies gibt die Prüfsumme der Werte in einer Gruppe zurück und NULL-Werte werden in diesem Fall ignoriert. Dies funktioniert auch mit der neuen Analysefunktion OVER-Klausel in SQL Server 2005.

BINARY_CHECKSUM: Wie der Name schon sagt, gibt dies den binären Prüfsummenwert zurück, der über eine Zeile oder eine Reihe von Ausdrücken berechnet wird. Der Unterschied zwischen CHECKSUM und BINARY_CHECKSUM besteht im generierten Wert für die Zeichendatentypen. Ein Beispiel für einen solchen Unterschied sind die Werte, die für "DECIPHER" und "decipher" generiert werden. Im Fall einer BINARY_CHECKSUM sind sie unterschiedlich, während sie für die CHECKSUM-Funktion (unter der Annahme, dass wir eine Groß- und Kleinschreibung unempfindliche Installation der Instanz haben) gleich sind. Ein weiterer Unterschied liegt im Vergleich von Ausdrücken. BINARY_CHECKSUM() gibt denselben Wert zurück, wenn die Elemente zweier Ausdrücke denselben Typ und die gleiche Byte-Repräsentation haben. "2Volvo Director 20" und "3Volvo Director 30" ergeben daher den gleichen Wert, während die CHECKSUM() -Funktion den Typ auswertet und die beiden Zeichenfolgen vergleicht, und wenn sie gleich sind, wird nur der gleiche Wert zurückgegeben.

Beispiel:
STRING              BINARY_CHECKSUM_USAGE    CHECKSUM_USAGE
------------------- ----------------------    -----------
2Volvo Director 20  -1356512636                -341465450
3Volvo Director 30  -1356512636                -341453853
4Volvo Director 40  -1356512636                -341455363

0 Stimmen

Ich habe das als Antwort akzeptiert, weil er den Link gepostet hat. Die Antwort von Kuya ist eine Kopie&Austausch von dieser Seite.

19 Stimmen

Es wird also besser sein, bis der Link verrottet, dann wird es schlechter.

0 Stimmen

Dieser Link wird von meiner Netzwerksicherheit blockiert. Kann jemand die Antwort von dieser Seite kopieren und einfügen?

9voto

user250718 Punkte 87

HASHBYTES mit MD5 ist 5 Mal langsamer als CHECKSUM, ich habe dies auf einer Tabelle mit über 1 Million Zeilen getestet und jeden Test 5 Mal durchgeführt, um einen Durchschnitt zu erhalten.

Interessanterweise benötigt CHECKSUM genau die gleiche Zeit wie BINARY_CHECKSUM.

Hier ist mein Beitrag mit den vollständigen Ergebnissen veröffentlicht: http://networkprogramming.wordpress.com/2011/01/14/binary_checksum-vs-hashbytes-in-sql/

2 Stimmen

Das beantwortet die Frage nicht.

6voto

Pete Punkte 1

Ich habe festgestellt, dass Kollisionsprüfungen (d.h. zwei unterschiedliche Werte, die denselben Prüfsummengenerator zurückgeben) häufiger vorkommen als die meisten Leute denken. Wir haben eine Tabelle von Währungen, die den ISO-Währungscode als PK verwenden. In einer Tabelle mit weniger als 200 Zeilen gibt es drei Paare von Währungscodes, die dieselbe Binary_Checksum() zurückgeben:

  • "ETB" und "EUR" (Äthiopischer Birr und Euro) geben beide 16386 zurück.
  • "LTL" und "MDL" (Litauischer Litas und Moldau-Leu) geben beide 18700 zurück.
  • "TJS" und "UZS" (Somoni und Usbekistan Som) geben beide 20723 zurück.

Dasselbe geschieht mit ISO-Ländercodes: "de" und "eu" (Deutsch und Baskisch) geben beide 1573 zurück.

Das Ändern von Binary_Checksum() in Checksum() behebt das Problem in diesen Fällen... aber in anderen Fällen mag es nicht helfen. Deshalb empfehle ich, gründlich zu testen, bevor man sich allzu sehr auf die Einzigartigkeit dieser Funktionen verlässt.

1 Stimmen

Nicht eine Kritik, sondern eine Warnung: das Gegenteil kann wahr sein. Es gibt Fälle, in denen checksum () Kollisionen produzieren wird, aber Binary_Checksum() nicht, also nehmen Sie diesen Ratschlag nicht als allgemein gültig: "die generierten Werte für "DECIPHER" und "dechiffrieren" werden im Fall einer BINARY_CHECKSUM unterschiedlich sein, aber gleich für die CHECKSUM-Funktion".

1 Stimmen

@AarasonLS: Wir können Duplikate mit Binary_CheckSum haben. Überprüfen Sie dieses Beispiel: SELECT BINARY_CHECKSUM(16 ,'EP30461105',1) AS BinaryCheckSumEx UNION ALL SELECT BINARY_CHECKSUM(21 ,'EP30461155',1) AS BinaryCheckSumEx

5voto

Yasir Punkte 4207

Seien Sie vorsichtig beim Verwenden von CHECSUM, möglicherweise erhalten Sie ein unerwartetes Ergebnis. Die folgenden Anweisungen erzeugen den gleichen Prüfsummewert;

SELECT CHECKSUM (N'iPhone', 5, 4102)
SELECT CHECKSUM (N'PlayStation Now – Sony startet Spiele-Streaming im Sommer 2014', 238, 13096)

2 Stimmen

Das ist zu erwarten. Prüfsummen sollten nicht zur Eindeutigkeit, sondern zur Eingrenzung des Suchbereichs verwendet werden.

2voto

Es ist einfach, Kollisionen von CHECKSUM() zu erhalten. HASHBYTES() wurde in SQL 2005 hinzugefügt, um die System-Hashfunktion von SQL Server zu verbessern. Daher empfehle ich Ihnen, sich auch damit als Alternative zu befassen.

0 Stimmen

Greg, es wäre hilfreich, die genauen Unterschiede zu kennen, damit man eine informierte Entscheidung über das vorliegende Problem treffen kann. Ich habe mein Problem bereits gelöst, hatte jedoch Schwierigkeiten, weitere detaillierte Informationen zu finden. Deshalb habe ich diese SO-Seite für andere mit komplexeren Problemen erstellt.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X