MySQL :: MySQL 5.6 リファレンスマニュアル :: 20.2.1 ストアドルーチンの構文

8.0 English
5.7 English
5.6 English
5.5 English

MySQL 5.6 リファレンスマニュアル / ... / ストアドルーチンの構文

20.2.1 ストアドルーチンの構文

ストアドルーチンはプロシージャーまたは関数のどちらかです。ストアドルーチンは、CREATE PROCEDURE および CREATE FUNCTION ステートメントで作成されます (セクション13.1.15「CREATE PROCEDURE および CREATE FUNCTION 構文」を参照してください)。プロシージャーは CALL ステートメントを使用して呼び出され (セクション13.2.1「CALL 構文」を参照してください)、出力変数の使用でのみ値を戻すことができます。関数は、ほかの関数とまったく同様に (つまり、関数の名前を呼び出すことによって) ステートメント内部から呼び出すことができ、スカラー値を戻すことができます。ストアドルーチンの本体では、複合ステートメントを使用できます (セクション13.6「MySQL 複合ステートメント構文」を参照してください)。

ストアドルーチンは、DROP PROCEDURE および DROP FUNCTION ステートメントで削除でき (セクション13.1.26「DROP PROCEDURE および DROP FUNCTION 構文」を参照してください)、ALTER PROCEDURE および ALTER FUNCTION ステートメントで変更できます (セクション13.1.5「ALTER PROCEDURE 構文」を参照してください)。

ストアドプロシージャーまたはストアドファンクションは、特定のデータベースに関連付けられています。これにはいくつかの問題があります。

ルーチンが呼び出されると、暗黙の USE db_name が実行されます (その後、ルーチンが終了すると元に戻ります)。ストアドルーチン内での USE ステートメントは許可されていません。
データベース名でルーチン名を修飾できます。これは現在のデータベースに存在しないルーチンを参照する場合に使用できます。たとえば、testデータベースに関連するストアドプロシージャー p またはストアドファンクション f を呼び出すには、CALL test.p() または test.f() と指定します。
データベースを削除すると、そのデータベースに関連付けられたすべてのストアドルーチンも削除されます。

ストアドファンクションは再帰関数にはできません。

ストアドプロシージャーでの再帰は許可されていますが、デフォルトでは無効になっています。再帰を有効にするには、max_sp_recursion_depth サーバーシステム変数を正の値に設定します。ストアドプロシージャーの再帰により、スレッドスタック領域の要求が増加します。max_sp_recursion_depth の値を増やした場合、サーバー起動時に thread_stack の値を増やすことによってスレッドスタックサイズを増やすことが必要な場合もあります。詳細は、セクション5.1.4「サーバーシステム変数」を参照してください。

MySQL では、通常の SELECT ステートメントをストアドプロシージャー内で (つまり、カーソルまたはローカル変数を使用せずに) 使用できるようにする非常に役立つ拡張をサポートしています。このようなクエリーの結果セットは単にクライアントに直接送信されます。複数の SELECT ステートメントは複数の結果セットを生成するので、クライアントは複数の結果セットをサポートしている MySQL クライアントライブラリを使用する必要があります。これは、クライアントが、4.1 以降の MySQL のバージョンからクライアントライブラリを使用する必要があることを意味します。クライアントは、接続するときに、CLIENT_MULTI_RESULTS オプションも指定する必要があります。C プログラムの場合、これは、mysql_real_connect()C API 関数で実行できます。セクション23.8.7.53「mysql_real_connect()」およびセクション23.8.17「複数ステートメント実行の C API サポート」を参照してください。

PREV HOME UP NEXT

User Comments

User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.

Posted by Graham Wideman on July 7, 2014

Functions and Procedures clarification
---------------------------------------

An alternative summary of functions versus procedures:

Functions
---------
Inputs: Takes a list of arguments, all are inputs.
Could also get input from running a query?

Outputs: Produces a single return value -- see RETURN clause. Can be any valid MySQL data type.

(Can that return value be a result set? Other docs say that "functions cannot return a result set", but this probably means "cannot return a result set direct to the client", which is something _procedures_ can do. So far as I can tell, functions cannot return a cursor, which would be a related concept.)

Calling method: Can be used where a built-in function like ABS() might be used, such as in an assignment, expression, or where a field value is expected.

Procedures
----------
Inputs: Takes a list of arguments. Procedure definition specifies whether these arguments are for input and/or output, via IN, OUT or INOUT.

Could also get input from running a query.

Outputs: Unlike a Function, does not produce a return value per se. However, can send values back to caller via OUT or INOUT arguments.

Also, procedures can contain a bare SELECT statement, which sends a result set to the client. A procedure can contain multiple such SELECT statements, if other details enable the client to receive multiple result sets.

Calling method: Caller uses CALL statement.

Syntax within Functions and Procedures
--------------------------------------------
The current doc page does mention "the body of a stored routine can use compound statements" . Here "compound statement" encompasses all the syntax you might expect relating to procedural programming, like variables, assignments, flow control and so forth.