ここに記載されている規制のうちには、すべてのストアド ルーチン、つまりストアド プロシージャとストアド ファンクションの両方に適用するものがあります。またあるものは、ストアド ファンクションのみにあてはまり、ストアド プロシージャには関係しません。

ストアド ファンクションに適用されるすべての規制は、トリガにもあてはまります。

ストアド ルーチンは、任意の SQL 文を取り込むことはできません。次のステートメントは利用不可です:

ストアド ファンクションでは、次の予備のステートメントまたは操作が不許可になっています ( ストアド プロシージャには適合しない ):

規制のあるものは通常、ストアド ファンクションとトリガに適用されるがストアド プロシージャには当てはまらないということになっていますが、ストアド ファンクション内またはトリガ内から実行されたストアド プロシージャには、それらの規制が適用されますので注意してください。例えば、FLUSH をストアド プロシージャで使用することはできますが、そうしたストアド プロシージャをストアド ファンクションやトリガから呼び出すことができません。

ルーチン パラメータ、ローカル変数、テーブル カラムに同じ識別子を使用することは可能です。また、同じローカル変数名を入れ子になったブロックで使うこともできます。例 :

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;

その場合、識別子が曖昧になるため、次の優先順位ルールが適用されます :

テーブル カラムが変数より優先されないという場合、その挙動は標準のものではありません。

ストアド ルーチンの使用は、反復の問題の原因になる場合があります。この問題については 項17.4. 「ストアドルーチンとトリガのバイナリログ」 で詳しく述べられています。

INFORMATION_SCHEMA スキーマは PARAMETERS テーブルをまだ持っていませんので、ランタイムでルーチン パラメータ情報を得る必要のあるアプリケーションは、SHOW CREATE 文のアウトプットを構文解析するなどの回避策を取らなければなりません。

ストアド ルーチンのデバッグ機能は存在しません。

CALL 文を準備することはできません。これはサーバ側のプリペアド ステートメントでも、SQL プリペアド ステートメントでも同じです。

UNDO ハンドラはサポートされていません。

FOR ループはサポートされていません。

サーバ スレッド間の作業の問題を防ぐため、クライアントがステートメントを発行する際、サーバはステートメントの実行に利用できるルーチンとトリガのスナップショットを使用します。これは、ステートメントの実行の間に使用される可能性のあるプロシージャ、関数、トリガのリストを算出してロードし、そしてステートメントの実行に進むということです。これにより、ステートメントが実行される間、他のスレッドが実行するルーチンに変化がないということになります。

RENAME DATABASE 文が、ストアド ルーチンを新たなスキーマ名に変えることはありません。 項12.1.18. 「RENAME DATABASE 構文」 参照。

トリガには、次の予備のステートメントまたは操作が利用不可になっています :

MySQL Cluster のストアド ルーチンおよびトリガ.  ストアド ファンクション、ストアド プロシージャ、およびトリガはすべて、NDB 保存エンジンを使用したテープルにサポートされていますが、それらは MySQL サーバ間に Cluster SQL ノードとして自動的に伝播しないということを忘れないでください。その原因は次になります :

MySQL Cluster テーブルに作用するすべてのストアド ルーチンまたはトリガは、そのストアド ルーチンまたはトリガを使用したいクラスタに関与する各 MySQL サーバの、適切な CREATE PROCEDURE 、CREATE FUNCTION 、または CREATE TRIGGER 文を実行することによって再作成されなければなりません。同様に、既存のストアド ルーチンまたはトリガのいかなる変更も、クラスタにアクセスする各 MySQL Server の適切な ALTER または DROP 文を使用して、すべての Cluster SQL ノードで明示的に実行される必要があります。