1

私は DB の専門家ではありませんが、かなり大規模な MySQL DB の実稼働の責任の一部を、やや無能であるが時折才能を発揮しているように見える人物から受け継いでいます。ほとんどの問題は自分で解決できましたが、これは私を困惑させ、どこにも対処していません。

準備されたステートメントのラッパーにすぎないストアド プロシージャを使用する正当な理由はありますか?

これらの行に沿ったもの：

CREATE PROCEDURE foo_search (IN searchParam1 int, IN searchParam2 varchar(255))
BEGIN
    SET @local1 = searchParam1;
    SET @local2 = searchParam2;
    PREPARE stmt FROM 
        '...'; --Fairly complex nested select statement
    EXECUTE stmt USING @local1, @local2;
END

以上です。プリペアド ステートメントについての私の理解では、その利点は、入力のサニタイズ (使用する PHP フレームワークによって既に処理されています) と、やり取りのやり取りの削減 (ストアド プロシージャ内にあることで妥協) にあるということです。

この純粋で単純な意味のない狂気なのか、それとも何かが足りないのでしょうか?

4

2 に答える 2

0

マイクは2つの正当な理由を挙げました。さらにいくつかあります：

  1. CALL foo_search(searchParam1, searchParam2)毎回SQLステートメント全体を送信するよりもデータが少なくなるため、ネットワークトラフィックの量が削減されます。

  2. サーバーでステートメントを準備すると、パフォーマンスが向上する場合があります。いくつかの異なる方法をベンチマークした後、複雑なSQLステートメントの場合、サーバー上でステートメントを1回だけ準備すると、最高のパフォーマンスが得られることがわかりました。次に例を示します。

CREATE PROCEDURE foo_search (IN searchParam1 int, IN searchParam2 varchar(255))
BEGIN
    SET @local1 = searchParam1;
    SET @local2 = searchParam2;
    IF ISNULL(@foo_search_prepared) THEN
        SET @foo_search_prepared = TRUE;

        PREPARE stmt FROM 
            '...'; --Fairly complex nested select statement
    END IF; 
    EXECUTE stmt USING @local1, @local2;
END
于 2012-10-13T00:02:23.607 に答える
0

あるかもしれません。

おそらく、その男は、準備されたステートメントをサポートしていない DB 接続ライブラリを使用していたので、同等の効果を得たいだけだったのでしょう。

おそらく、彼はそのストアド プロシージャをトリガーから呼び出したかったのでしょう。

于 2012-10-12T23:21:08.750 に答える