MySQL 저장 프로시저는 생성 시점의 환경을 보존할까?

네, 실제로 MySQL은 저장 프로시저가 생성된 시점의 환경을 그대로 보존합니다. 즉, 프로시저 내부에서 사용된 설정(예: SQL 모드)은 생성 당시의 값으로 고정되며, 이후 세션 환경이 바뀌어도 기존 프로시저의 동작에는 영향을 주지 않습니다.

다음 예제를 통해 쉽게 이해할 수 있습니다. 이 예제에서는 문자열을 연결하기 위해 이중 막대(||) 연산자를 사용합니다. 이 연산자는 SQL 모드가 'ANSI'일 때만 문자열 연결로 동작합니다. 하지만 이후 SQL 모드를 비(非)ANSI로 변경하더라도 기존에 생성된 프로시저는 마치 원래 설정이 여전히 유효한 것처럼 정상적으로 작동합니다.

예제

먼저 SQL 모드를 'ANSI'로 설정한 뒤, 이중 막대 연산자를 사용하는 저장 프로시저 Con_string()을 생성하고 호출합니다.

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)

ANSI 모드에서는 ||가 문자열 연결 연산자로 해석되므로 결과가 'ab'로 출력됩니다.

이제 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)

위 결과 집합은 SQL 모드를 비ANSI로 변경했음에도 불구하고 기존 프로시저 Con_string()이 여전히 동일한 결과('ab')를 반환하는 것을 보여줍니다. 이는 프로시저가 생성 시점의 SQL 모드 환경을 그대로 유지하고 있기 때문입니다.

반면, 변경된 환경에서 새로 생성되는 프로시저는 더 이상 이중 막대를 문자열 연결 연산자로 받아들이지 않습니다. 아래 예제에서 새로 만든 Con_string1()은 같은 코드임에도 결과가 0으로 나타나고 경고가 발생합니다.

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, 2 warnings (0.00 sec)

정리

저장 프로시저는 생성 시점의 sql_mode 등 세션 환경을 내부적으로 함께 저장합니다.
이후 세션의 SQL 모드가 변경되어도 기존 프로시저의 동작에는 영향을 주지 않습니다.
변경된 환경은 새로 생성하는 프로시저부터 적용됩니다.