일의 특성과 업무를 완벽하게 파악후 쿼리에서 그 특성에 맞게

잘 짜는게 최고입니다. 그래서 업무를 알아야 쿼리문을 만들 수 있는거 같습니다.

그런후에는 인덱스를 잘 요리하시면 되겠습니다.

여러쿼리문의 실행계획 분석도 좋은 방법이지 않나요?

실행계획을 분석하는 것이 좋습니다.

최소한대로 logical  io 를 줄여 주면서... 쓸대없는 io 를 발생시키지

않는 방법으로 쿼리를 만드셔야 겠죠?

인덱스의 설계도 아주 중요할 테구요..

그리고 정확한 성능 지표는 최초 실행 elasped time 이 아닌

메모리(buffer) 에 올라온 상태의 성능을 지표로 삼으셔야 합니다.

그렇기 때문에...buffer get 의 io 여부가 아주 중요하겠죠,,

동시 트랜잭션 사용자를 예측하여 전체적인 쿼리에 대한

stress test 를 해보실 것을 권장합니다.

수고하세요..

오래된 글이지만 한자 더 적으려 합니다.

sql 은 집합연산이고

4gl 프로그램은 순차 프로그램 성격이 강합니다.

그럼 처음 프로그램 하시던 분이 쿼리를 짜면 절차지향적

프로그램을 쿼리문에 적용하기 쉽습니다.

하지만 이 멋진 sql 은 성격이 좀 달라서 문론 절차지향적인

프로그램도 잘 처리하지만 집합연산을 시키면 아주

날아 다닙니다.

하나의 예를 들자면 대부분의 커서는 일반쿼리로 풀 수 있습니다.

보통 컨설턴트들이 12시간에 돌아가던것을 15분으로 줄였습니다.

이렇게 결과를 발표하는 것을 많이 보았을 겁니다.

이런 경우의 대부분은 커서 연산으로 sql call 을 자꾸 날리고 disk 의

io 를 대량으로 발생시켜 문제가 되는 경우가 대부분입니다.

예를 들어 부서와 사원테이블이 있을때

1 경리부

2 개발부

이런식의 코드성 데이터가 있을때

사원테이블에 경리부 개발부를 비정규화 해서 넣으면

조인도 하지 않아두 되고 속도도 빠를 것이다 라고 착각 하는

분이 많습니다.

실제 데이터를 넣고 테스트 해보면 조인 쿼리와 정규화 된것이

훨씬 빠르다는 것을 알 수 있습니다. 이것은 바로 sql io 의 중요

성을 나타내 주는 아주 대표적인 예 입니다.