Skip navigation links
MySQL 5.1 Referenzhandbuch :: I Feature-Beschränkungen :: I.1 Beschränkungen bei gespeicherten Routinen und Triggern
I.2 Beschränkungen von serverseitigen Cursorn »
Section Navigation      [Toggle]

I.1. Beschränkungen bei gespeicherten Routinen und Triggern

Einige hier aufgeführten Beschränkungen gelten für alle gespeicherten Routinen, also sowohl für gespeicherte Prozeduren als auch für gespeicherte Funktionen. Manche Beschränkungen gelten nur für gespeicherte Funktionen, aber nicht für gespeicherte Prozeduren.

Alle Beschränkungen für gespeicherte Funktionen gelten auch für Trigger. Außerdem sind Trigger zurzeit noch nicht für Fremdschlüsselaktionen aktiviert.

Gespeicherte Routinen dürfen keine beliebigen SQL-Anweisungen enthalten. Die folgenden Anweisungen sind unzulässig:

  • die Sperranweisungen LOCK TABLES und UNLOCK TABLES

  • LOAD DATA und LOAD TABLE

  • Vorbereitete SQL-Anweisungen (PREPARE, EXECUTE, DEALLOCATE PREPARE). Folge: Sie können in gespeicherten Routinen kein dynamisches SQL benutzen (indem Sie Anweisungen dynamisch als Strings generieren und dann ausführen). Diese Einschränkung wird in MySQL 5.0.13 für gespeicherte Prozeduren aufgehoben, gilt aber weiterhin für gespeicherte Funktionen und Trigger.

Für gespeicherte Funktionen (nicht aber gespeicherte Prozeduren) sind zusätzlich folgende Anweisungen unzulässig:

  • Anweisungen, die ein explizites oder implizites Commit oder Rollback ausführen

  • Anweisungen, die eine Ergebnismenge zurückgeben. Dazu gehören auch SELECT-Anweisungen, die keine INTO var_list-Klausel besitzen, sowie SHOW-Anweisungen. Eine Funktion kann eine Ergebnismenge entweder mit SELECT ... INTO var_list oder mit einem Cursor und FETCH-Anweisungen verarbeiten. Siehe Abschnitt 19.2.7.3, „SELECT ... INTO-Anweisung“.

  • FLUSH-Anweisungen

  • Rekursive Anweisungen. Das bedeutet, dass gespeicherte Funktionen nicht rekursiv benutzt werden können.

Achtung: Obwohl einige Beschränkungen normalerweise zwar für gespeicherte Funktionen und Trigger, aber nicht für gespeicherte Prozeduren gelten sollten, gelten sie dennoch für gespeicherte Prozeduren, wenn diese aus einer gespeicherten Funktion oder einem Trigger heraus aufgerufen werden. So können Sie zwar FLUSH in einer gespeicherten Prozedur verwenden, aber keine derartige gespeicherte Prozedur aus einer gespeicherten Funktion oder einem Trigger heraus aufrufen.

Es ist möglich, denselben Bezeichner für eine Routine, einen Parameter, eine lokale Variable und eine Tabellenspalte zu benutzen. Zudem kann derselbe lokale Variablenname in geschachtelten Blöcken eingesetzt werden. Zum Beispiel: 

CREATE PROCEDURE p (i INT)
BEGIN
  DECLARE i INT DEFAULT 0;
  SELECT i FROM t;
  BEGIN
    DECLARE i INT DEFAULT 1;
    SELECT i FROM t;
  END;
END;

In solchen Fällen ist der Bezeichner nicht mehr eindeutig, sodass folgende Präzedenzregeln gelten:

  • Eine lokale Variable hat Vorrang vor einem Routinenparameter oder einer Tabellenspalte.

  • Ein Routinenparameter hat Vorrang vor einer Tabellenspalte.

  • Eine lokale Variable in einem inneren Block hat Vorrang vor einer lokalen Variablen in einem äußeren Block.

Dass Tabellenspalten nicht Vorrang vor Variablen haben, ist ein nichtstandardmäßiges Verhalten.

Die Verwendung von gespeicherten Routinen kann Replikationsprobleme verursachen. Dieses Thema wird in Abschnitt 19.4, „Binärloggen gespeicherter Routinen und Trigger“, eingehender behandelt.

Da INFORMATION_SCHEMA noch keine PARAMETERS-Tabelle hat, müssen Anwendungen, die Daten von Routinenparametern zur Laufzeit benötigen, Workarounds einsetzen, also beispielsweise die Ausgabe der SHOW CREATE-Anweisungen parsen.

Es gibt keine Debuggingfähigkeiten für gespeicherte Routinen.

CALL-Anweisungen dürfen keine vorbereiteten Anweisungen sein. Das gilt sowohl für serverseitige vorbereitete Anweisungen als auch für vorbereitete SQL-Anweisungen.

UNDO-Handler werden nicht unterstützt.

FOR-Schleifen werden nicht unterstützt.

Um Probleme mit der Interaktion zwischen Server-Threads zu verhindern, verwendet der Server, wenn ein Client eine Anweisung gibt, einen Schnappschuss der Routinen und Trigger, die zur Ausführung dieser Anweisung verfügbar sind. Das bedeutet, dass der Server eine Liste von Prozeduren, Funktionen und Triggern berechnet, die bei der Ausführung der Anweisung eingesetzt werden dürfen, diese lädt und dann zur Ausführung der Anweisung schreitet. Die Folge: Während der Ausführung erkennt der Server keine Änderungen an Routinen, die von anderen Threads vorgenommen werden.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.