このページは機械翻訳したものです。

A.4 MySQL 8.0 FAQ: ストアドプロシージャーおよびストアドファンクション

A.4.1. MySQL 8.0 はストアドプロシージャーおよびストアドファンクションをサポートしていますか。

A.4.2. MySQL のストアドプロシージャーおよびストアドファンクションについてのドキュメントはどこにありますか。

A.4.3. MySQL のストアドプロシージャーのディスカッションフォーラムはありますか。

A.4.4. ストアドプロシージャーの ANSI SQL 2003 仕様はどこにありますか。

A.4.5. ストアドルーチンを管理するにはどうすればよいですか。

A.4.6. 特定のデータベースのすべてのストアドプロシージャーおよびストアドファンクションを表示する方法はありますか。

A.4.7. ストアドプロシージャーはどこに格納されますか。

A.4.8. ストアドプロシージャーまたはストアドファンクションをパッケージにグループ化することはできますか。

A.4.9. ストアドプロシージャーは別のストアドプロシージャーを呼び出すことができますか。

A.4.10. ストアドプロシージャーはトリガーを呼び出すことができますか。

A.4.11. ストアドプロシージャーはテーブルにアクセスできますか。

A.4.12. ストアドプロシージャーには、アプリケーションエラーを発生させるステートメントはありますか。

A.4.13. ストアドプロシージャーには例外処理はありますか。

A.4.14. MySQL 8.0 のストアドルーチンは結果セットを返すことができますか。

A.4.15. ストアドプロシージャーで WITH RECOMPILE はサポートされますか。

A.4.16. mod_plsql を Apache のゲートウェイとして使用してデータベース内のストアドプロシージャーと直接やり取りするのと同等の機能は MySQL にありますか。

A.4.17. ストアドプロシージャーに入力として配列を渡すことはできますか。

A.4.18. ストアドプロシージャーに IN パラメータとしてカーソルを渡すことはできますか。

A.4.19. ストアドプロシージャーの OUT パラメータとしてカーソルを返すことはできますか。

A.4.20. デバッグのために、ストアドルーチン内の変数の値を出力できますか。

A.4.21. ストアドプロシージャー内でトランザクションをコミットまたはロールバックできますか。

A.4.22. MySQL 8.0 のストアドプロシージャーおよびストアドファンクションはレプリケーションで動作しますか。

A.4.23. レプリケーションソースサーバー上に作成されたストアドプロシージャーおよびストアドファンクションはレプリカにレプリケートされますか。

A.4.24. ストアドプロシージャーおよびストアドファンクション内で実行されたアクションはどのようにレプリケートされますか。

A.4.25. レプリケーションでストアドプロシージャーおよびストアドファンクションを使用するための特別なセキュリティー要件はありますか。

A.4.26. ストアドプロシージャーおよびストアドファンクションのアクションをレプリケートする場合の制限は何ですか。

A.4.27. 前述の制限は、MySQL が point-in-tim

A.4.28. 前述の制限を修正するために何が行われていますか。

A.4.1.	MySQL 8.0 はストアドプロシージャーおよびストアドファンクションをサポートしていますか。
	はい。 MySQL 8.0 は、ストアドプロシージャーとストアドファンクションの 2 種類のストアドルーチンをサポートしています。
A.4.2.	MySQL のストアドプロシージャーおよびストアドファンクションについてのドキュメントはどこにありますか。
	セクション25.2「ストアドルーチンの使用」を参照してください。
A.4.3.	MySQL のストアドプロシージャーのディスカッションフォーラムはありますか。
	はい。 https://forums.mysql.com/list.php?98 を参照してください。
A.4.4.	ストアドプロシージャーの ANSI SQL 2003 仕様はどこにありますか。
	残念ながら、正式な仕様は無料では入手できません (ANSI は有料で販売しています)。 ただし、「SQL-99 完全、本当に」 by Peter Gulutzan や Trudy Pelzer など、ストアドプロシージャの適用範囲を含む標準の包括的な概要を提供する書籍があります。
A.4.5.	ストアドルーチンを管理するにはどうすればよいですか。
	ストアドルーチンに明快な命名スキームを使用することはよい管理方法です。 ストアドプロシージャーは、CREATE [FUNCTION|PROCEDURE]、ALTER [FUNCTION|PROCEDURE]、DROP [FUNCTION|PROCEDURE]、および SHOW CREATE [FUNCTION|PROCEDURE] を使用して管理できます。 既存のストアドプロシージャーに関する情報を取得するには、INFORMATION_SCHEMA データベースの ROUTINES テーブル (セクション26.30「INFORMATION_SCHEMA ROUTINES テーブル」を参照してください) を使用します。
A.4.6.	特定のデータベースのすべてのストアドプロシージャーおよびストアドファンクションを表示する方法はありますか。
	はい。 dbname という名前のデータベースの場合、INFORMATION_SCHEMA.ROUTINES テーブルに対して次のクエリーを使用します。 SELECT ROUTINE_TYPE, ROUTINE_NAME FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA='dbname'; 詳細は、セクション26.30「INFORMATION_SCHEMA ROUTINES テーブル」を参照してください。 ストアドルーチンの本体は、SHOW CREATE FUNCTION (ストアドファンクションの場合) または SHOW CREATE PROCEDURE (ストアドプロシージャーの場合) を使用して表示できます。 詳細は、セクション13.7.7.9「SHOW CREATE PROCEDURE ステートメント」を参照してください。
A.4.7.	ストアドプロシージャーはどこに格納されますか。
	ストアドプロシージャは、データディクショナリの一部である mysql.routines テーブルおよび mysql.parameters テーブルに格納されます。 これらのテーブルに直接アクセスすることはできません。 かわりに、INFORMATION_SCHEMA ROUTINES テーブルおよび PARAMETERS テーブルをクエリーします。 セクション26.30「INFORMATION_SCHEMA ROUTINES テーブル」およびセクション26.20「INFORMATION_SCHEMA PARAMETERS テーブル」を参照してください。 SHOW CREATE FUNCTION を使用してストアドファンクションに関する情報を取得し、SHOW CREATE PROCEDURE を使用してストアドプロシージャに関する情報を取得することもできます。 セクション13.7.7.9「SHOW CREATE PROCEDURE ステートメント」を参照してください。
A.4.8.	ストアドプロシージャーまたはストアドファンクションをパッケージにグループ化することはできますか。
	いいえ。これは MySQL 8.0 ではサポートされません。
A.4.9.	ストアドプロシージャーは別のストアドプロシージャーを呼び出すことができますか。
	はい。
A.4.10.	ストアドプロシージャーはトリガーを呼び出すことができますか。
	ストアドプロシージャーでは、トリガーが実行される UPDATE などの SQL ステートメントを実行できます。
A.4.11.	ストアドプロシージャーはテーブルにアクセスできますか。
	はい。 ストアドプロシージャーは、必要に応じて 1 つ以上のテーブルにアクセスできます。
A.4.12.	ストアドプロシージャーには、アプリケーションエラーを発生させるステートメントはありますか。
	はい。 MySQL 8.0 には、SQL 標準の SIGNAL ステートメントおよび RESIGNAL ステートメントが実装されています。 セクション13.6.7「条件の処理」を参照してください。
A.4.13.	ストアドプロシージャーには例外処理はありますか。
	MySQL には、SQL 標準に従った HANDLER 定義が実装されています。 詳細は、セクション13.6.7.2「DECLARE ... HANDLER ステートメント」を参照してください。
A.4.14.	MySQL 8.0 のストアドルーチンは結果セットを返すことができますか。
	ストアドプロシージャーは返すことができますが、ストアドファンクションは返すことができません。 ストアドプロシージャー内で通常の SELECT を実行すると、結果セットがクライアントに直接返されます。 これを機能させるには、MySQL 4.1 以上のクライアント/サーバープロトコルを使用する必要があります。 つまり、PHP では、古い mysql 拡張機能ではなく mysqli 拡張機能を使用する必要があります。
A.4.15.	ストアドプロシージャーで WITH RECOMPILE はサポートされますか。
	MySQL 8.0 にはありません。
A.4.16.	mod_plsql を Apache のゲートウェイとして使用してデータベース内のストアドプロシージャーと直接やり取りするのと同等の機能は MySQL にありますか。
	MySQL 8.0 には同等の機能はありません。
A.4.17.	ストアドプロシージャーに入力として配列を渡すことはできますか。
	MySQL 8.0 にはありません。
A.4.18.	ストアドプロシージャーに IN パラメータとしてカーソルを渡すことはできますか。
	MySQL 8.0 では、カーソルはストアドプロシージャーの内部でのみ使用できます。
A.4.19.	ストアドプロシージャーの OUT パラメータとしてカーソルを返すことはできますか。
	MySQL 8.0 では、カーソルはストアドプロシージャーの内部でのみ使用できます。 ただし、SELECT でカーソルをオープンしない場合、結果はクライアントに直接送信されます。 変数に対して SELECT INTO を発行することもできます。 セクション13.2.10「SELECT ステートメント」を参照してください。
A.4.20.	デバッグのために、ストアドルーチン内の変数の値を出力できますか。
	はい。これは、ストアドプロシージャーでは行うことができますが、ストアドファンクションでは行うことはできません。 ストアドプロシージャー内で通常の SELECT を実行すると、結果セットがクライアントに直接返されます。 これを機能させるには、MySQL 4.1 (以上) のクライアント/サーバープロトコルを使用する必要があります。 つまり、PHP では、古い mysql 拡張機能ではなく mysqli 拡張機能を使用する必要があります。
A.4.21.	ストアドプロシージャー内でトランザクションをコミットまたはロールバックできますか。
	はい。 ただし、ストアドファンクション内でトランザクション操作を実行することはできません。
A.4.22.	MySQL 8.0 のストアドプロシージャーおよびストアドファンクションはレプリケーションで動作しますか。
	はい。ストアドプロシージャおよびファンクションで実行される標準アクションは、レプリケーションソースサーバーからレプリカにレプリケートされます。 セクション25.7「ストアドプログラムバイナリロギング」で詳しく説明されているいくつかの制限があります。
A.4.23.	レプリケーションソースサーバー上に作成されたストアドプロシージャーおよびストアドファンクションはレプリカにレプリケートされますか。
	はい。オブジェクトが両方のサーバーに存在するように、レプリケーションソースサーバーで通常の DDL ステートメントを介して実行されるストアドプロシージャおよびファンクションの作成はレプリカにレプリケートされます。 ストアドプロシージャーおよびストアドファンクションに対する ALTER ステートメントおよび DROP ステートメントもレプリケートされます。
A.4.24.	ストアドプロシージャーおよびストアドファンクション内で実行されたアクションはどのようにレプリケートされますか。
	MySQL は、ストアドプロシージャで発生した各 DML イベントを記録し、それらの個々のアクションをレプリカにレプリケートします。 ストアドプロシージャーを実行するために行われた実際の呼び出しはレプリケートされません。 データを変更するストアドファンクションは、各ファンクション内で行われた DML イベントとしてではなく、関数呼び出しとしてログ記録されます。
A.4.25.	レプリケーションでストアドプロシージャーおよびストアドファンクションを使用するための特別なセキュリティー要件はありますか。
	はい。 レプリカにはソースバイナリログから読み取られたステートメントを実行する権限があるため、レプリケーションでストアドファンクションを使用するための特別なセキュリティー制約が存在します。 レプリケーションまたは一般のバイナリロギング (ポイントインタイムリカバリのための) がアクティブである場合、MySQL の DBA には選択できるセキュリティーオプションが 2 つあります。 ストアドファンクションを作成するユーザーに、SUPER 権限を付与する必要があります。 または、DBA は log_bin_trust_function_creators システム変数に 1 を設定できます。これにより、標準の CREATE ROUTINE 権限を持ったユーザーがストアドファンクションを作成できます。
A.4.26.	ストアドプロシージャーおよびストアドファンクションのアクションをレプリケートする場合の制限は何ですか。
	ストアドプロシージャーに埋め込まれている決定性のない (ランダムな) アクションまたは時間ベースのアクションは、正しくレプリケートされないことがあります。 その性質上、ランダムに生成された結果は予測できず、正確には再現できません。したがって、レプリカにレプリケートされたランダムなアクションは、ソースで実行されたものを反映しません。 ストアドファンクションを DETERMINISTIC として宣言するか、log_bin_trust_function_creators システム変数を 0 に設定すると、ランダムな操作によってランダムな値が生成されなくなります。 また、ストアドプロシージャでのアクションのタイミングはレプリケーションに使用されるバイナリログを介して再現できないため、レプリカでは時間ベースのアクションを再現できません。 バイナリログには、DML イベントのみが記録され、タイミング制約は含まれていません。 最後に、大規模な DML アクション (一括挿入など) 中にエラーが発生した非トランザクションテーブルでは、ソースが DML アクティビティから部分的に更新される可能性があるというレプリケーションの問題が発生する可能性がありますが、エラーが発生したためレプリカは更新されません。 回避策として、IGNORE キーワードを使用して関数 DML アクションを実行すると、エラーの原因となったソースの更新が無視され、エラーの原因とならない更新がレプリカにレプリケートされます。
A.4.27.	前述の制限は、MySQL が point-in-tim
	レプリケーションに影響する制限が、ポイントインタイムリカバリに同様に影響します。
A.4.28.	前述の制限を修正するために何が行われていますか。
	ステートメントベースのレプリケーションまたは行ベースのレプリケーションのいずれかを選択できます。 元のレプリケーションの実装は、ステートメントベースのバイナリロギングに基づいています。 行ベースのバイナリロギングによって、前述の制限が解決されます。 複合レプリケーションも使用できます (--binlog-format=mixed を指定してサーバーを起動します)。 このハイブリッド形式のレプリケーション 「knows」 ステートメントレベルレプリケーションを安全に使用できるかどうか、または行レベルレプリケーションが必要かどうか。 追加情報については、セクション17.2.1「レプリケーション形式」を参照してください。