ストアドルーチンはプロシージャーまたは関数のどちらかです。 ストアドルーチンは、CREATE PROCEDURE および CREATE FUNCTION ステートメントで作成されます (セクション13.1.17「CREATE PROCEDURE ステートメントおよび CREATE FUNCTION ステートメント」を参照してください)。 プロシージャーは CALL ステートメントを使用して呼び出され (セクション13.2.1「CALL ステートメント」を参照してください)、出力変数の使用でのみ値を戻すことができます。 関数は、ほかの関数とまったく同様に (つまり、関数の名前を呼び出すことによって) ステートメント内部から呼び出すことができ、スカラー値を戻すことができます。 ストアドルーチンの本体では、複合ステートメントを使用できます (セクション13.6「複合ステートメントの構文」を参照してください)。
ストアドルーチンは、DROP PROCEDURE および DROP FUNCTION ステートメントで削除でき (セクション13.1.29「DROP PROCEDURE および DROP FUNCTION ステートメント」を参照してください)、ALTER PROCEDURE および ALTER FUNCTION ステートメントで変更できます (セクション13.1.7「ALTER PROCEDURE ステートメント」を参照してください)。
ストアドプロシージャーまたはストアドファンクションは、特定のデータベースに関連付けられています。 これにはいくつかの問題があります。
ルーチンが呼び出されると、暗黙の
USEが実行されます (その後、ルーチンが終了すると元に戻ります)。 ストアドルーチン内でのdb_nameUSEステートメントは許可されていません。データベース名でルーチン名を修飾できます。 これは現在のデータベースに存在しないルーチンを参照する場合に使用できます。 たとえば、
testデータベースに関連するストアドプロシージャーpまたはストアドファンクションfを呼び出すには、CALL test.p()またはtest.f()と指定します。データベースを削除すると、そのデータベースに関連付けられたすべてのストアドルーチンも削除されます。
ストアドファンクションは再帰関数にはできません。
ストアドプロシージャーでの再帰は許可されていますが、デフォルトでは無効になっています。 再帰を有効にするには、max_sp_recursion_depth サーバーシステム変数を正の値に設定します。 ストアドプロシージャーの再帰により、スレッドスタック領域の要求が増加します。 max_sp_recursion_depth の値を増やした場合、サーバー起動時に thread_stack の値を増やすことによってスレッドスタックサイズを増やすことが必要な場合もあります。 詳細は、セクション5.1.8「サーバーシステム変数」を参照してください。
MySQL では、通常の SELECT ステートメントをストアドプロシージャー内で (つまり、カーソルまたはローカル変数を使用せずに) 使用できるようにする非常に役立つ拡張をサポートしています。 このようなクエリーの結果セットは単にクライアントに直接送信されます。 複数の SELECT ステートメントは複数の結果セットを生成するので、クライアントは複数の結果セットをサポートしている MySQL クライアントライブラリを使用する必要があります。 これは、クライアントが、4.1 以降の MySQL のバージョンからクライアントライブラリを使用する必要があることを意味します。 クライアントは、接続するときに、CLIENT_MULTI_RESULTS オプションも指定する必要があります。 C プログラムの場合、これは、mysql_real_connect()C API 関数で実行できます。 mysql_real_connect()およびMultiple Statement Execution Supportを参照してください。
MySQL 8.0.22 以降では、ストアドプロシージャのステートメントによって参照されるユーザー変数のタイプは、プロシージャの初回起動時に決定され、その後プロシージャが起動されるたびにこのタイプが保持されます。