http://www.mysqlkorea.co.kr
한글매뉴얼 5.0 , 한글매뉴얼 5.1 , MySQL 5.1 HA , 사용자매뉴얼
한글매뉴얼 5.0  
한글매뉴얼 5.1  
MYSQL 5.1 HA  
사용자매뉴얼  
영문매뉴얼  
최신글
mysql master - s…
김선영 아나운서…
'연애의 맛' 시즌…
[대림 NEWS] 대림…
연애의맛 정준 소…
 
다운로드 > 개발자 존 > 다운로드
 

100.1. 스토어드 루틴 및 트리거 사용의 제약 사항

 

여기에서는 모든 스토어드 루틴에 적용되는 몇몇 제약 사항들을 나열한다; , 스토어드 프로시저 및 스토어드 함수 모두에 해당한다. 하지만, 이 중에 몇 가지는 스토어드 프로시저에는 해당하지 않고, 스토어드 함수에만 적용되는 것도 있다.

스토어드 함수에 적용되는 제약 사항은 모든 트리거에도 적용된다. 또한, 트리거는 아직까지는 외국어에 대해서는 동작하지 않는다

 

노트 : 만일, SELECT ... INTO 명령문 같은 SQL문장이 한 컬럼을 참조하고 컬럼 이름과 동일한 로컬 변수를 선언할 경우, MySQL은 이 참조를 변수의 이름으로 해석한다. 이것은 비표준적인 동작이다; 선행 명령은 일반적으로 컬럼 이름이며, 그 다음이 SQL 변수이고, 그 다음은 파라미터 값이다. Section 17.2.9.3, “SELECT ... INTO 명령문을 참조.

스토어드 루틴은 임의의 SQL명령문을 포함할 수 없다.  아래의 명령문은 스토어드 루틴 내에서는 사용할 수 없다:

  • 테이블-관리(table-maintenance)명령문 CHECK TABLES OPTIMIZE TABLES. Note: 이 제약 사항은MySQL 5.0.17에서 해결 예정임.
  • 잠금 명령문(locking statement) LOCK TABLES, UNLOCK TABLES.
  • LOAD DATA LOAD TABLE.
  • SQL 준비 명령문 (PREPARE, EXECUTE, DEALLOCATE PREPARE). 함축적 의미: 스토어드 루틴 내에서는 동적 SQL을 사용할 수 없다(스트링 형태로 명령문을 구성한 다음에 실행). 이 제약 사항은 MySQL 5.0.13 에서 해결 예정; 아직까지는 스토어드 함수 및 트리거에 해당됨.

스토어드 함수(스토어드 프로시저는 해당 없음)에 대해서는, 추가적으로 아래의 명령문을 사용할 수 없다:

  • explicit 또는 implicit commit 또는rollback을 수행하는 명령문.
  • 결과 셋(result set)을 돌려주는 명령문. 여기에는 INTO 조항 및 SHOW 명령문을 갖고 있지 않는 SELECT 명령문도 포함됨.  함수는 SELECT ... INTO  또는 커서와 FETCH 명령문을 사용해서 결과 셋을 진행할 수 있다.
  • FLUSH 명령문. 스토어드 프로시저 내에 FLUSH 를 사용할 경우, 이 스토어드 프로시저는 스토어드 함수 또는 트리거로부터 선언 되어질 수 없음을 주의. Note: MySQL 5.0.10 이전에는, CREATE FUNCTION 이 있는 스토어드 함수는 극히 예외적인 경우를 제외하고는 테이블에 대한 참조를 가질 수 없었다. 테이블 참조를 갖고 있는 몇몇 SET 명령문이 여기에 해당되는데, 예를 들면 SET a:= (SELECT MAX(id) FROM t) 이며,  변수의 값을 직접 가져오는 SELECT 명령문이 여기에 해당되는데, 예를 들면, SELECT i INTO var1 FROM t 이다.
  • 반복 명령문. , 스토어드 함수는 반복적으로 사용할 수 없다.

비록 몇몇 제약 사항들이 일반적으로 스토어드 함수 및 트리거에만 적용되고 스토어드 프로시저에는 해당되지 않는다 하더라도, 이러한 제약 사항들이 스토어드 함수 또는 트리거로 인해 호출되어질 경우에는 스토어드 프로시저에도 적용된다는 점을 유의해야 한다

동일한 식별자(identifier)를 루틴 파라미터, 로컬 변수, 그리고 테이블 컬럼으로 사용하는 것은 가능하다. 또한 동일한 변수 이름을 네스티드 블록내에서 사용하는 것도 가능하다. 예를 들면:

 

CREATE PROCEDURE p (i INT)

BEGIN

  DECLARE i INT DEFAULT 0;

  SELECT i FROM t;

  BEGIN

    DECLARE i INT DEFAULT 1;

    SELECT i FROM t;

  END;

END;

 

이러한 경우 식별자는 불분명한 상태가 되며 아래의 선행 법칙이 적용된다:

  • 로컬 변수는 루틴 파라미터 또는 테이블 컬럼보다 앞선다
  • 루틴 파라미터는 테이블 컬럼보다 앞선다
  • 내부 블록내의 로컬 변수는 외부 블록내의 로컬 변수보다 앞선다

테이블 컬럼이 변수 s보다 선행 수행을 하지 못하는 것은 비표준이다.

스토어드 루틴의 사용은 리플리케이션 문제를 야기할 수 있다. 이 문제는 나중에 Section 17.4, “스토어드 루틴 트리거에 바이너리로 로깅에서 다루기로 한다.

INFORMATION_SCHEMA 는 아직까지PARAMETERS 테이블을 갖지 못하는데, 따라서 런타임에서 루틴 파라미터 정보를 가질 필요가 있는 애플리케이션들은 반드시 SHOW CREATE 명령문의 결과를 파싱(parsing)하는 것과 같은 일련의 작업을 수행해야 한다. 아직까지는 스토어드 루틴 디버깅을 손쉽게 해주는 기능은 없다.

 

CALL 명령문은 사용할 수 없다. 이 점은 서버쪽의 프리페어드 명령문(prepared statements) SQL 프리페어드 명령문 모두에 해당되는 것이다.

 

클라이언트가 명령문을 처리할 때, 서버는 서버 쓰레드간의 상호 작용 문제를 해소하기 위해서, 명령문을 실행하는 루틴과 트리거의 스냅샷을 사용한다. , 서버는 명령문이 실행되는 동안 사용될 수 있는 프로시저의 리스트, 함수 및 트리거를 계산하고 그 다음에 실제 명령문을 실행한다. 이것은 명령문이 실행되는 동안, 다른 쓰레드가 실행하는 루틴의 변화를 의식하지 않는다는 것을 의미한다.

UNDO 핸들러는 지원되지 않으며, FOR 루프 역시 지원하지 않는다.

 

상위
MySQL Korea 사이트의 컨텐츠 소유권은 (주)상상이비즈에 있으므로 무단전재를 금합니다.
ⓒ 2010-2011 ssebiz All Rights Reserved.