준비된 진술을 사용할 때 단점이 있습니까?

Question

나는 준비된 진술에 대해 많은 것을 읽었으며, 내가 읽은 모든 것에 대해 아무도 사용하지 않을 경우의 단점에 대해 이야기하지 않는다. 그러므로 사람들이 간과하는 경향이있는 "용들이있을 것"이라는 점이 있는지 궁금합니다.

Answer 1

준비된 문은 구문 분석되어 미리 컴파일 된 SQL 문으로 바운드 변수가 실행될 때까지 대기합니다.

실행 된 모든 명령문은 조만간 준비됩니다 (구문 분석, 최적화, 컴파일 및 실행해야 함).

준비된 문장은 구문 분석, 최적화 및 컴파일 결과를 재사용합니다.

보통 데이터베이스 시스템은 준비된 쿼리를 직접 사용하지 않더라도 쿼리 준비에 약간의 시간을 절약하기 위해 일종의 최적화를 사용합니다.

Oracle 예를 들어, 쿼리를 구문 분석 할 때 먼저 라이브러리 캐시가 검사되고 동일한 문이 이미 구문 분석 된 경우 캐시 된 실행 계획이 대신 사용됩니다.

Answer 2

문을 한 번만 사용하거나 동적 SQL 문을 자동으로 생성하는 경우 (모든 매개 변수를 올바르게 이스케이프 처리하거나 매개 변수에 의 안전 문자 만있는 경우) 준비 문을 사용하지 않아야합니다.

Answer 3

제가 생각할 수있는 유일한 단점은 서버에서 메모리를 차지한다는 것입니다. 그다지 문제는 아니지만 문제가 될 수있는 몇 가지 중요한 경우가있을 수 있습니다.하지만 어떤 것도 생각하기가 어렵습니다.

Answer 4

prepared statement와 dynamic sql의 다른 작은 문제가 있습니다. 디버깅하기가 더 어려울 수 있습니다. 동적 SQL을 사용하면 항상 문제가있는 쿼리를 로그 파일에 기록하고 프로그램에서 보는 것과 똑같이 서버에서 직접 실행할 수 있습니다. 준비된 명령문을 사용하면 충돌 데이터에서 결정된 특정 매개 변수 집합을 사용하여 쿼리를 테스트하는 데 약간의 작업이 필요할 수 있습니다. 그러나 그보다 훨씬 더 많은 것은 아닙니다. 추가 보안으로 비용을 확실히 정당화 할 수 있습니다.

Answer 5

경우에 따라 데이터베이스 엔진은 준비된 문을 사용할 때 열등한 쿼리 계획을 수립 할 수 있습니다. 왜냐하면 데이터베이스 엔진은 준비에 대한 실제 바인딩 값을 가지지 않고 올바른 가정을 할 수 없기 때문입니다.

http://www.postgresql.org/docs/current/static/sql-prepare.html

에서 '메모'섹션 그래서으로 빠르게 어떤 알아 제표를 작성하지 않고 쿼리를 테스트 할 가치가있을 수도 있습니다. 모든 ORM이 그렇게 할 수있는 것은 아니지만 준비된 구문을 사용할지 여부를 결정할 수 있습니다.