MySQL: @Variable vs. Variable. Was ist der Unterschied?

Question

In einer anderen Frage, die ich gestellt habe, hat mir jemand gesagt, dass es einen Unterschied gibt zwischen:

@variable

und:

variable

in MySQL. Er erwähnte auch, dass MSSQL einen Batch-Bereich und MySQL einen Session-Bereich hat. Kann jemand dies für mich näher erläutern?

Answer 1

MySQL hat ein Konzept von benutzerdefinierte Variablen .

Es handelt sich dabei um locker typisierte Variablen, die irgendwo in einer Sitzung initialisiert werden können und ihren Wert bis zum Ende der Sitzung behalten.

Sie sind mit einem vorangestellten @ Zeichen, etwa so: @var

Sie können diese Variable mit einer SET Anweisung oder innerhalb einer Abfrage:

SET @var = 1

SELECT @var2 := 2

Wenn Sie eine Stored Procedure in MySQL entwickeln, können Sie die Eingabeparameter übergeben und die lokalen Variablen deklarieren:

DELIMITER //

CREATE PROCEDURE prc_test (var INT)
BEGIN
    DECLARE  var2 INT;
    SET var2 = 1;
    SELECT  var2;
END;
//

DELIMITER ;

Diesen Variablen werden keine Präfixe vorangestellt.

Der Unterschied zwischen einer Prozedurvariablen und einer sitzungsspezifischen benutzerdefinierten Variablen besteht darin, dass eine Prozedurvariable reinitialisiert wird, um NULL jedes Mal, wenn die Prozedur aufgerufen wird, während die sitzungsspezifische Variable dies nicht tut:

CREATE PROCEDURE prc_test ()
BEGIN
    DECLARE var2 INT DEFAULT 1;
    SET var2 = var2 + 1;
    SET @var2 = @var2 + 1;
    SELECT  var2, @var2;
END;

SET @var2 = 1;

CALL prc_test();

var2  @var2
---   ---
2     2

CALL prc_test();

var2  @var2
---   ---
2     3

CALL prc_test();

var2  @var2
---   ---
2     4

Wie Sie sehen können, var2 (Prozedurvariable) wird bei jedem Aufruf der Prozedur reinitialisiert, während @var2 (sitzungsspezifische Variable) ist es nicht.

(Zusätzlich zu den benutzerdefinierten Variablen kann MySQL auch hat einige vordefinierte "Systemvariablen", die "globale Variablen" sein können, wie z.B. @@global.port oder "Sitzungsvariablen" wie z. B. @@session.sql_mode ; diese "Sitzungsvariablen" haben nichts mit den sitzungsspezifischen benutzerdefinierten Variablen zu tun).

Answer 2

In MySQL, @variable zeigt eine benutzerdefinierte Variable . Sie können Ihre eigene definieren.

SET @a = 'test';
SELECT @a;

Außerhalb von gespeicherten Programmen kann ein variable , ohne @ ist ein Systemvariable die Sie nicht selbst definieren können.

Der Geltungsbereich dieser Variablen ist die gesamte Sitzung. Das bedeutet, dass die Variable immer noch verwendet werden kann, solange die Verbindung zur Datenbank besteht.

Dies steht im Gegensatz zu MSSQL, wo die Variable nur im aktuellen Stapel von Abfragen (gespeicherte Prozedur, Skript oder sonstiges) verfügbar ist. In einem anderen Stapel in derselben Sitzung ist sie nicht verfügbar.

Answer 3

MSSQL verlangt, dass Variablen innerhalb von Prozeduren DECLAREd sind und die Leute die @Variable Syntax ( DECLARE @TEXT VARCHAR(25) = 'text' ). Außerdem erlaubt MS Deklarationen innerhalb jedes Blocks in der Prozedur, im Gegensatz zu MySQL, das alle DECLAREs am Anfang verlangt.

Obwohl es auf der Kommandozeile gut funktioniert, bin ich der Meinung, dass die Verwendung der set = @variable innerhalb gespeicherter Prozeduren in MySQL ist riskant. Es gibt keinen Geltungsbereich und Variablen leben über die Grenzen des Geltungsbereichs hinaus. Das ist vergleichbar mit Variablen in JavaScript, die ohne den var Präfix, die dann den globalen Namensraum bilden und unerwartete Kollisionen und Überschreibungen verursachen.

Ich hoffe, dass die guten Leute von MySQL es erlauben werden DECLARE @Variable auf verschiedenen Blockebenen innerhalb einer gespeicherten Prozedur. Beachten Sie die @ (am Schild). Die @ hilft, Variablennamen von Tabellenspaltennamen zu trennen, da sie oft identisch sind. Natürlich kann man immer ein "v" oder "l_" als Präfix hinzufügen, aber das @ ist ein praktischer und prägnanter Weg, um den Variablennamen mit der Spalte übereinstimmen zu lassen, aus der Sie die Daten extrahieren möchten, ohne sie zu verklumpen.

MySQL ist neu auf dem Gebiet der gespeicherten Prozeduren, und sie haben für ihre erste Version gute Arbeit geleistet. Es wird ein Vergnügen sein, zu sehen, wohin sie sich hier entwickeln und zu beobachten, wie die serverseitigen Aspekte der Sprache reifen.

Answer 4

Im Prinzip verwende ich UserDefinedVariables (mit @ vorangestellt) innerhalb von Stored Procedures. Das macht das Leben einfacher, vor allem wenn ich diese Variablen in zwei oder mehr Stored Procedures benötige. Nur wenn ich eine Variable nur in EINER Stored Procedure brauche, dann verwende ich eine Systemvariable (ohne vorangestelltes @).

@Xybo: Ich verstehe nicht, warum die Verwendung von @Variablen in StoredProcedures riskant sein soll. Könntest du bitte "scope" und "boundaries" etwas einfacher erklären (für mich als Neuling)?

Answer 5

@variable ist sehr nützlich, wenn der Aufruf von gespeicherte Verfahren aus einer in Java, Python usw. geschriebenen Anwendung. Es gibt Fälle, in denen beim ersten Aufruf Variablenwerte erstellt werden, die in den Funktionen der nachfolgenden Aufrufe benötigt werden.

Nebenbemerkung zu PL/SQL (Oracle)

Der Vorteil zeigt sich in Oracle PL/SQL wobei diese Variablen 3 verschiedene Geltungsbereiche haben:

• Funktionsvariable für die der Geltungsbereich beim Beenden der Funktion endet.
• Paketkörper-Variablen definiert am Anfang des Pakets und außerhalb aller Funktionen, deren Geltungsbereich die Sitzung und die Sichtbarkeit das Paket ist.
• Paketvariable deren Variable Session und deren Sichtbarkeit global ist.

Meine Erfahrung mit PL/SQL

Ich habe eine Architektur entwickelt, bei der der gesamte Code in PL/SQL geschrieben ist. Diese werden von einer in Java geschriebenen Middleware aufgerufen. Es gibt zwei Arten von Middleware. Die eine ist für Aufrufe von einem Client zuständig, der ebenfalls in Java geschrieben ist. Die andere ist für Aufrufe von einem Browser vorgesehen. Die Client-Funktion ist zu 100 Prozent in JavaScript implementiert. Zum Schreiben von Anwendungen in PL/SQL wird ein Befehlssatz anstelle von HTML und JavaScript verwendet.

Ich habe nach der gleichen Möglichkeit gesucht, um die in PL/SQL geschriebenen Codes in eine andere Datenbank zu portieren. Die nächstgelegene Möglichkeit, die ich gefunden habe, ist Postgres . Aber alle Variablen haben einen Funktionsumfang.

Stellungnahme zu @ in MySQL

Ich freue mich, dass zumindest diese @ Möglichkeit ist in MySQL vorhanden. Ich glaube nicht, dass Oracle dieselbe Möglichkeit, die in PL/SQL verfügbar ist, in MySQL Stored Procedures einbauen wird, da dies die Verkäufe der Oracle-Datenbank beeinträchtigen könnte.