はい。 MySQL 8.0 は、ストアドプロシージャーとストアドファンクションの 2 種類のストアドルーチンをサポートしています。

セクション25.2「ストアドルーチンの使用」を参照してください。

はい。 https://forums.mysql.com/list.php?98 を参照してください。

残念ながら、正式な仕様は無料では入手できません (ANSI は有料で販売しています)。 ただし、「SQL-99 完全、本当に」 by Peter Gulutzan や Trudy Pelzer など、ストアドプロシージャの適用範囲を含む標準の包括的な概要を提供する書籍があります。

ストアドルーチンに明快な命名スキームを使用することはよい管理方法です。 ストアドプロシージャーは、CREATE [FUNCTION|PROCEDURE]、ALTER [FUNCTION|PROCEDURE]、DROP [FUNCTION|PROCEDURE]、および SHOW CREATE [FUNCTION|PROCEDURE] を使用して管理できます。 既存のストアドプロシージャーに関する情報を取得するには、INFORMATION_SCHEMA データベースの ROUTINES テーブル (セクション26.30「INFORMATION_SCHEMA ROUTINES テーブル」を参照してください) を使用します。

はい。 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 ステートメント」を参照してください。

ストアドプロシージャは、データディクショナリの一部である 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 ステートメント」を参照してください。

いいえ。これは MySQL 8.0 ではサポートされません。

はい。

ストアドプロシージャーでは、トリガーが実行される UPDATE などの SQL ステートメントを実行できます。

はい。 ストアドプロシージャーは、必要に応じて 1 つ以上のテーブルにアクセスできます。

はい。 MySQL 8.0 には、SQL 標準の SIGNAL ステートメントおよび RESIGNAL ステートメントが実装されています。 セクション13.6.7「条件の処理」を参照してください。

MySQL には、SQL 標準に従った HANDLER 定義が実装されています。 詳細は、セクション13.6.7.2「DECLARE ... HANDLER ステートメント」を参照してください。

ストアドプロシージャーは返すことができますが、ストアドファンクションは返すことができません。 ストアドプロシージャー内で通常の SELECT を実行すると、結果セットがクライアントに直接返されます。 これを機能させるには、MySQL 4.1 以上のクライアント/サーバープロトコルを使用する必要があります。 つまり、PHP では、古い mysql 拡張機能ではなく mysqli 拡張機能を使用する必要があります。

MySQL 8.0 にはありません。

MySQL 8.0 には同等の機能はありません。

MySQL 8.0 にはありません。

MySQL 8.0 では、カーソルはストアドプロシージャーの内部でのみ使用できます。

MySQL 8.0 では、カーソルはストアドプロシージャーの内部でのみ使用できます。 ただし、SELECT でカーソルをオープンしない場合、結果はクライアントに直接送信されます。 変数に対して SELECT INTO を発行することもできます。 セクション13.2.10「SELECT ステートメント」を参照してください。

はい。これは、ストアドプロシージャーでは行うことができますが、ストアドファンクションでは行うことはできません。 ストアドプロシージャー内で通常の SELECT を実行すると、結果セットがクライアントに直接返されます。 これを機能させるには、MySQL 4.1 (以上) のクライアント/サーバープロトコルを使用する必要があります。 つまり、PHP では、古い mysql 拡張機能ではなく mysqli 拡張機能を使用する必要があります。

はい。 ただし、ストアドファンクション内でトランザクション操作を実行することはできません。

はい。ストアドプロシージャおよびファンクションで実行される標準アクションは、レプリケーションソースサーバーからレプリカにレプリケートされます。 セクション25.7「ストアドプログラムバイナリロギング」で詳しく説明されているいくつかの制限があります。

はい。オブジェクトが両方のサーバーに存在するように、レプリケーションソースサーバーで通常の DDL ステートメントを介して実行されるストアドプロシージャおよびファンクションの作成はレプリカにレプリケートされます。 ストアドプロシージャーおよびストアドファンクションに対する ALTER ステートメントおよび DROP ステートメントもレプリケートされます。

MySQL は、ストアドプロシージャで発生した各 DML イベントを記録し、それらの個々のアクションをレプリカにレプリケートします。 ストアドプロシージャーを実行するために行われた実際の呼び出しはレプリケートされません。

データを変更するストアドファンクションは、各ファンクション内で行われた DML イベントとしてではなく、関数呼び出しとしてログ記録されます。

はい。 レプリカにはソースバイナリログから読み取られたステートメントを実行する権限があるため、レプリケーションでストアドファンクションを使用するための特別なセキュリティー制約が存在します。 レプリケーションまたは一般のバイナリロギング (ポイントインタイムリカバリのための) がアクティブである場合、MySQL の DBA には選択できるセキュリティーオプションが 2 つあります。

ストアドプロシージャーに埋め込まれている決定性のない (ランダムな) アクションまたは時間ベースのアクションは、正しくレプリケートされないことがあります。 その性質上、ランダムに生成された結果は予測できず、正確には再現できません。したがって、レプリカにレプリケートされたランダムなアクションは、ソースで実行されたものを反映しません。 ストアドファンクションを DETERMINISTIC として宣言するか、log_bin_trust_function_creators システム変数を 0 に設定すると、ランダムな操作によってランダムな値が生成されなくなります。

また、ストアドプロシージャでのアクションのタイミングはレプリケーションに使用されるバイナリログを介して再現できないため、レプリカでは時間ベースのアクションを再現できません。 バイナリログには、DML イベントのみが記録され、タイミング制約は含まれていません。

最後に、大規模な DML アクション (一括挿入など) 中にエラーが発生した非トランザクションテーブルでは、ソースが DML アクティビティから部分的に更新される可能性があるというレプリケーションの問題が発生する可能性がありますが、エラーが発生したためレプリカは更新されません。 回避策として、IGNORE キーワードを使用して関数 DML アクションを実行すると、エラーの原因となったソースの更新が無視され、エラーの原因とならない更新がレプリカにレプリケートされます。

レプリケーションに影響する制限が、ポイントインタイムリカバリに同様に影響します。

ステートメントベースのレプリケーションまたは行ベースのレプリケーションのいずれかを選択できます。 元のレプリケーションの実装は、ステートメントベースのバイナリロギングに基づいています。 行ベースのバイナリロギングによって、前述の制限が解決されます。

複合レプリケーションも使用できます (--binlog-format=mixed を指定してサーバーを起動します)。 このハイブリッド形式のレプリケーション 「knows」 ステートメントレベルレプリケーションを安全に使用できるかどうか、または行レベルレプリケーションが必要かどうか。

追加情報については、セクション17.2.1「レプリケーション形式」を参照してください。