SQL 이란..
SQL도 프로그래밍 언어와 같은 '언어'이다.
Query Language : 질의 언어인데
Structured : 구조적이고
집합적이고 선언적인 질의 언어이다.
'선언적'인 것이 어떤 의미인지 몰라 찾아봤다.
쉽게 이해할 수 있는 글이었다 : https://iborymagic.tistory.com/73
내용들 중 확 와닿았던 부분을 정리한다.
'선언적'이란 것은, 우리가 무엇을 얻고자 하는가에 관해서만 묘사하고 있고, 그것을 어떻게 얻는가에 관해서는 알려주지 않는다.
현실에서는, '무엇'을 얻기 위해 어떻게 해야하는지는 이미 알고 있음을 기반하고 있다고 볼 수 있고
코드에서는, 메서드 `add()`가 내부에서 어떤 것을 하는지 모르겠지만, 우선 이름만으로 이해 될 수 있다.
사실 많은 선언적(Declarative) 접근 방식들의 기반에는 일종의 '명령적(Imperative) 추상화'가 존재한다는 언급을 한다.
결국 SQL도 무엇을 할 것인지만 알려주는 선언적 언어이며, 우리는 SQL의 문법을 알고 있기 때문에 이해할 수 있는 것이다.
SQL을 수행하여 만들어내는 결과 집합은 특정 프로시저에 의해 만들어지는데,
SQL 옵티마이저라는 DBMS 내부 엔진 (기능)을 통해 '프로시저'를 만들어 낸다.
만들어진 프로시저트를 컴파일해서 실행 가능한 상태로 만드는 전 과정을 'SQL 최적화'라고 한다.
SQL 최적화 단계...
총 세가지로 나열할 수 있다.
1) SQL문을 이루는 구성요소를 분석하거나 문법적 오류가 없는지 확인하고, 의미상 오류가 없는지 확인하는 과정을 거친다.
2) SQL 옵티마이저(엔진)를 통해 미리 수집해놓은 시스템이나 오브젝트 통계 정보를 바탕으로 다양한 실행 경로를 생성해서, 그중 가장 효율적인 1개를 비교/선택한다. -> 최적화 단계.
3) SQL 옵티마이저가 선택한 실행 경로를 실행 가능한 상태로 포맷팅하는 과정을 거친다. (로우 소스 생성기 에 의해)
SQL 옵티마이저 란...
옵티마이저가 진행하는 최적화 단계에서는
각 다양한 실행 경로의 예상 비용을 선정하고, 가장 최저인 예상 비용을 나타내는 실행 계획을 선택하는 것이다.
각 실행 계획의 예상 비용을 산정할 때에는 데이터 딕셔너리에 미리 수집해 둔 오브젝트 통계와 시스템 통계 정보를 이용한다.
실행 계획은 내비게이션이 경로를 선택하는 것과 같은 기능이다.
사용자는 이동 경로를 미리 확인해서 선택한 경로가 마음에 들지 않으면 원하는 경로로 바꿀 수도 있다.
실행 계획은 SQL 옵티마이저가 생성한 처리 절차를 사용자가 확인할 수 있게 트리 구조로 표현하여 나타낸다.
-> SQL문이 수행될 때, 테이블을 스캔하는지 인덱스를 스캔하는지
어떤 인덱스를 스캔하는지 확인할 수 있다.
본인이 원하는 방식의 처리가 있다면, 실행 경로를 변경할 수 있다.
예상 비용은 쿼리를 수행하는 동안 발생할 것으로 예상하는 I/O 횟수, 예상 소요시간을 표현한 값이다.
이 값은 옵티마이저가 여러 통계정보를 활용해서 계산해낸 "예상" 수치이기 때문에 실제 수행할 때 발생하는 I/O 또는 시간과 차이가 날 수 있다.
옵티마이저가 선택한 실행 계획이 최선이 아닐 수 있다. 특히 SQL이 복잡할 수록 실수할 가능성이 크다.
이럴 때는 개발자가 직접 더 효율적인 액세스 경로를 찾아내서 경로를 바꿔줄 수도 있다.
이때 옵티마이저 힌트를 사용하면 된다.
구체적인 사용법은 필요할 때 찾아보면 좋겠다.
주의사항 몇가지만!
1. 힌트 안에 인자를 나열할 때에는 콤마 를 사용하지 않아야 한다.
2. 테이블을 지정할 때에는 스키마명까지 명시하면 안된다.
3. FROM 절 테이블명에 alias 를 지정했다면 힌트 내에서도 그 alias를 사용해야 한다.
옵티마이저의 선택에 맡길 수 있는 애플리케이션 환경이라면 힌트를 일부만 지정하면 되지만,
약간의 실수도 애플리케이션에 중대한 영향을 미치는 경우라면 꼼꼼히 힌트를 기술해줘야 한다.