MySQLのストアドプロシージャは作成時点の環境を保持するのか？

実は、MySQLではストアドプロシージャが作成された時点の環境（設定）を保持しています。つまり、プロシージャを作成した時点でのSQLモードなどの設定が、その後変更されても、すでに作成済みのプロシージャには影響しないという仕組みです。

この動作は、文字列を連結するために「||」（2本の縦棒）を使用する例で確認できます。「||」による文字列連結は、SQLモードが「ansi」の場合にのみ有効な記法です。しかし、その後SQLモードを非ANSIモードに変更しても、既存のプロシージャはあたかも元の設定が有効であるかのように動作し続けます。

具体例で確認してみよう

まず、SQLモードを「ansi」に設定してから、文字列を連結するストアドプロシージャを作成します。

mysql> Set sql_mode = 'ansi'//
Query OK, 0 rows affected, 1 warning (0.14 sec)

mysql> Create Procedure Con_string()
    -> SELECT 'a'||'b'//
Query OK, 0 rows affected (0.12 sec)

mysql> Call Con_string();
+----------+
| 'a'||'b' |
+----------+
| ab       |
+----------+
1 row in set (0.05 sec)

Query OK, 0 rows affected (0.05 sec)

この時点では、SQLモードが「ansi」なので、「||」による文字列連結が正しく機能し、「ab」という結果が返されています。

SQLモードを変更しても既存のプロシージャは影響を受けない

次に、SQLモードを空（非ANSIモード）に変更してから、同じプロシージャを再度呼び出してみます。

mysql> Set sql_mode = '';
Query OK, 0 rows affected (0.00 sec)

mysql> Call Con_string();
+----------+
| 'a'||'b' |
+----------+
| ab       |
+----------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

上記の結果セットを見ると、SQLモードを非ANSIモードに変更した後でも、プロシージャ「Con_string()」は依然として同じ結果（「ab」）を返していることがわかります。これは、プロシージャが作成された時点の環境（SQLモードがansiだった状態）を保持しているためです。

新しく作成するプロシージャには新しい設定が適用される

一方、現在の（非ANSIの）SQLモードで新しくプロシージャを作成するとどうなるでしょうか。新しいプロシージャでは「||」による文字列連結は受け付けられません。これは、SQLモードが非ANSIに変更されているためです。

mysql> create procedure Con_string1()
    -> Select 'a'||'b'//
Query OK, 0 rows affected (0.02 sec)

mysql> Call Con_string1()//
+----------+
| 'a'||'b' |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

Query OK, 0 rows affected, 2 warnings (0.00 sec)

ご覧のとおり、新しく作成したプロシージャ「Con_string1()」では、「||」が論理OR演算子として解釈され、結果として「0」が返されています。警告（warnings）も発生しており、文字列連結として機能していないことがわかります。

まとめ

• ストアドプロシージャは作成時点の環境（SQLモードなど）を保持します。
• その後SQLモードを変更しても、既存のプロシージャの動作は変わりません。
• ただし、新しく作成するプロシージャには変更後の設定が適用されます。

この特性を理解しておくと、SQLモードの変更が既存のストアドプロシージャに与える影響を正しく予測できるようになり、意図しない動作を防ぐことができます。