MySQLストアドプロシージャの最適化例_MySQL

WBOY
リリース: 2016-09-09 08:13:37
オリジナル
1166 人が閲覧しました

はじめに

データベース開発のプロセスでは、複雑なビジネス ロジックとデータベース操作が頻繁に発生します。このとき、データベース操作をカプセル化するためにストアド プロシージャが使用されます。プロジェクトに多くのストアド プロシージャがあり、記述が標準化されていない場合、将来のシステムの保守が困難になり、また、データ量が増えるとストアド プロシージャのロジックを理解することが困難になります。データベースが大きい場合、またはプロジェクトにストアド プロシージャに対する高いパフォーマンス要件がある場合、将来的にシステムのメンテナンスが困難になる可能性があります。そうしないと、個人的な経験から、最適化されたストアド プロシージャの速度が非常に遅くなる可能性があります。パフォーマンスの悪いストアド プロシージャよりも何百倍も効率的です。以下では、特定の MySQL ストアド プロシージャを最適化するプロセス全体を紹介します。

この記事では、最適化する必要があるストアド プロシージャは次のとおりです:

リーリー

ストアド プロシージャで使用されるテーブル tb_testnum は次の構造を持っています:

リーリー

ストレージプロセスで使用される別のテーブルtb_testnum_tmpは次の構造を持っています:

リーリー

2 つのテーブルの構造から、

tb_testnumtb_testnum_tmp に含まれるフィールドがまったく同じであることがわかります。ストアド プロシージャ pr_dealtestnum の機能は、tb_testnum_tmp テーブルのデータを挿入することです。入力パラメータに基づく tb_testnum テーブル。

明らかに、期待された機能は実現できていますが、ストアド プロシージャ

pr_dealtestnum のコードにはまだ改善の余地があります。

以下、段階的に最適化していきます。

最適化 1

ストアドプロシージャ

pr_dealtestnumの本体はinsert文ですが、このinsert文の中にselect文も含まれているというような書き方は変則的です。したがって、この挿入ステートメントを 2 つのステートメントに分割する必要があります。つまり、まず tb_testnum_tmp テーブルからデータを検索し、次にそれを tb_testnum テーブルに挿入します。変更されたストアド プロシージャは次のとおりです:

リーリー

最適化 2

tb_testnum

テーブルにデータを挿入する前に、そのデータがテーブルに既に存在するかどうかを確認する必要があります。存在する場合、それ以上のデータは挿入されません。同様に、tb_testnum_tmp テーブルのデータをクエリする前に、まずテーブルにデータが存在するかどうかを確認する必要があります。存在する場合は、テーブルからデータを検索できます。変更されたストアド プロシージャは次のとおりです: リーリー

最適化 3


tb_testnum

テーブルにデータを挿入する操作が正常に実行されたかどうかに関係なく、実行の結果を表す識別値が存在する必要があります。これにより、開発者はプログラム フローの追跡とデバッグも容易になります。つまり、各 Leave ステートメントの前に戻り値が存在する必要があり、そのための出力パラメーターを定義します。変更されたストアド プロシージャは次のとおりです:

リーリー

最適化 4


ステートメントでは、

tb_testnum

テーブルの後に特定のフィールド名がリストされていないことに気付きました。これも不規則です。将来のソフトウェア バージョンで新しいフィールドが insert into tb_testnum values(p_boxnumber,p_usertype);”tb_testnum テーブルに追加される場合、これはステートメントはエラーを報告する可能性が非常に高いため、tb_testnum テーブルにフィールドがいくつあるかに関係なく、挿入操作を実行するときに特定のフィールド名をリストする必要があるのが標準的な記述方法です。次のように: リーリー

最適化 5

insert ステートメントの実行後、MySQL に付属の
パラメータを使用して、挿入されたデータが成功したかどうかを判断し、開発者が実行結果を追跡できるようにします。このパラメータの値が 0 でない場合は、挿入が失敗したことを意味し、戻りパラメータ値を使用して操作が失敗したことを示します。変更されたストアド プロシージャは次のとおりです:

リーリー @error_count

概要

上記からわかるように、短いストアド プロシージャには最適化が必要な領域が非常に多くあり、ストアド プロシージャを作成するのは簡単ではないようです。実際、ストアド プロシージャに限らず、コードを記述するときは、ライフ サイクルの長い美しいコードを記述し、高品質なソフトウェア製品を開発できるように、コードの機能、読みやすさ、パフォーマンスなどの側面を考慮する必要があります。 。この記事が皆さんの MySQL ストアド プロシージャの学習に役立つことを願っています。ご支援に感謝いたします。

ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート