스토어드 루틴 및 트리거에 대한 제한 사항에 따라 동적 SQL을 사용할 수 없습니다 (버전 5.0.13 이상의 스토어드 프로 시저에 대한 제한 사항 해제). 왜이 제한이 있습니까? 왜 기능이나 트리거가 아닌 절차를 위해 들어 올리겠습니까?
스토어드 루틴 및 트리거에 대한 제한 사항에 따라 동적 SQL을 사용할 수 없습니다 (버전 5.0.13 이상의 스토어드 프로 시저에 대한 제한 사항 해제). 왜이 제한이 있습니까? 왜 기능이나 트리거가 아닌 절차를 위해 들어 올리겠습니까?
답변:
질문을 듣는 것만으로 두 가지 측면을 생각할 수 있습니다.
ASPECT # 1 : 함수는 결정적입니다
이 경우, 함수가 함수를 호출 할 때 어떤 매개 변수도 주어진 매개 변수 세트에 대해 동일한 리턴 데이터를 일관되게 표시해야 함을 의미합니다.
이제 함수의 정적 SQL을 기반으로 하루 중 다른 시간에 데이터를 수집하기 때문에 다른 응답을 생성하는 함수를 상상해보십시오. 어떤 의미에서, 동일한 매개 변수 세트가 주어질 때마다 동일한 테이블 및 열 세트를 조회 할 경우에도 여전히 DETERMINISTIC으로 간주 될 수 있습니다.
Dynamic SQL을 통해 함수의 기본 테이블을 변경할 수 있다면 어떨까요? DETERMINISTIC 함수의 정의를 위반하고 있습니다.
MySQL은이 옵션을 /etc/my.cnf에 추가했습니다.
log-bin-trust-function-creators이것은 지나치게 단순화 된 것일 수도 있지만 DETERMINISTIC 속성을 엄격하게 적용하지 않고 함수가 이진 로그에 데이터를 쓸 수 있도록합니다.
ASPECT # 2 : 트리거를 롤백 할 수 있어야합니다
기본적으로 MVCC에서만 2 차적으로 (지수 적으로) 증가하는 데이터가 있습니다. 결정적이지 않을 수있는 트리거로 SQL 롤백을 관리하는 프로세스는 가장 까다로울 수 있습니다.
이 두 가지 측면에 비추어, MySQL 개발자들은 이러한 것들에 대해 생각하고 제한을가함으로써 신속하게 해산했습니다.
그렇다면 왜 절차 제한을 해제해야합니까? 간단히 말해 결정적 속성이나 롤백에 대한 걱정은 없습니다.
이것은 좋은 질문이지만 답을 모르겠습니다. 나는 이것이 내부 팀으로 가야한다고 생각하지만, 그들이이 사이트에 커질 지 모른다. 그동안 답변을 추론하도록 도와 드리겠습니다.
우선 나는 이것을 본다 :
트리거 캐시는 기본 개체의 메타 데이터가 변경된시기를 감지하지 않습니다. 트리거가 테이블을 사용하고 트리거가 캐시에로드 된 이후 테이블이 변경된 경우 트리거는 오래된 메타 데이터를 사용하여 작동합니다.
그것은 그것이 그것과 관련이 있다고 생각하게 만듭니다. 메타 데이터를 모니터링하지 않으면 SQL을 다시 컴파일하지 않을 것입니다. 엔진 문제라는 의미입니다.
마찬가지로,이 블록을 읽을 때 동일한 것 (엔진)을 생각합니다.
클라이언트가 명령문을 발행 할 때 서버 스레드 간의 상호 작용 문제점을 방지하기 위해 서버는 명령문의 실행에 사용 가능한 루틴 및 트리거의 스냅 샷을 사용합니다. 즉, 서버는 명령문 실행 중에 사용될 수있는 프로 시저, 함수 및 트리거 목록을 계산하여로드 한 다음 명령문을 실행합니다. 이는 명령문이 실행되는 동안 다른 스레드가 수행하는 루틴의 변경 사항을 볼 수 없음을 의미합니다.
그래서 나는 그들이 왜 그것을 허용하지 않는지 완전히 확신하지 못하지만 추측 할 수 있습니다. 더 이상 도와 드릴 수 없어서 죄송합니다.이 문제를 좀 더 해결하기 위해 노력하고 있습니다. 가장 좋은 방법은 비공개 베타를 떠나면 일부 활성 MySQL 개발자를 희망하는 것입니다.)