MYSQL

Preparedstatement 사용이유

dodo1054 2022. 5. 17. 21:34
반응형

SQL 서버 엔진 쿼리 수행 시 과정

1. 구문 분석 및 정규화 단계 

  - 쿼리 문법이 제대로 작성되었는지 확인하고 테이블과 컬럼이 DB에 존재하는지 확인하는 단계

2. 컴파일 단계

  - 쿼리 컴파일

3. 쿼리 최적화 단계

  - 쿼리를 실행할 수 있는 방법의 수와 쿼리를 실행하는 각 방법의 비용을 알아내어 최적의 계획 선택

4. 캐시 단계

  - 쿼리 최적화 단계에서 캐시에 저장되므로 동일한 쿼리가 들어올 때마다 1,2,3 단계를 실행하지 않고

     동일한 쿼리가 들어왔을 경우 캐시를 찾아 실행

5. 실행 단계

   - 쿼리가 실행되고 데이터 반환

 

 

PreparedStatement(준비된 쿼리) 즉 쿼리의 틀을 미리 생성해놓음  

  - 동일한 쿼리를 여러번 반복 실행할 경우 성능을 향상시키기 위해 개발됨 

  - Placeholder Replacement 추가 단계가 있으며 런타임시 사용자가 입력한 데이터로 대체

     대체 후 최종 쿼리가 다시 구문을 분석하거나 컴파일하지 않는다.

  - 쿼리에서 데이터가 들어가는 부분을 제외하고 문법만 분석하고 SQL서버가 쿼리 계획을 세우고 최적화를 진행

  - 후에 사용자가 execute 시 미리 최적화된 쿼리에 데이터를 삽입하여 실행

 

PreparedStatement 보안적인 측면

  - SQL Injection 공격 방지하기 떄문에 보안성이 높다

      SQL Injection ?

           - 악의적인 SQL문을 실행시켜 데이터베이스를 비상적으로 조작하는 해킹방법

     

EX) $mysqli->sql_query("SELECT * FROM user WHERE username = '{user}' AND password = '{password}';

       위와같은 쿼리문에 OR 1=1 이라는 구문(무조건 참) 넣을경우 무조건 적으로 쿼리가 실행됨

 

   - 쿼리가 컴파일 되어 캐시된 이후에 Replacement 단계에서 사용자가 입력한 데이터로 대체되기 때문에 미리 컴파일 된 최종 쿼리는

      다시 컴파일 과정을 거치지 않는다. 그렇기 떄문에 쿼리의 원래 논리를 수정할 수 없고 SQL 주입 공격을 에방할 수 있다.

 

참고 블로그

https://velog.io/@jsj3282/Statement%EB%B3%B4%EB%8B%A4-Preparedstatement%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0%EC%84%B1%EB%8A%A5-%EB%B3%B4%EC%95%88-%EC%B8%A1%EB%A9%B4

 

 

       

 

 

 

 

반응형