튜닝?
SQL 쿼리 실행 순서
서브 쿼리를 제일 먼저 실행 > 나머지 본 쿼리들 실행 하는 순서
FROM 절로 서브 쿼리를 뺸 이유도 딱 한번 FROM 절에서 서브 쿼리를 먼저 실행 하므로
SELECT ? , subquery 에서는 셀렉 하나당 subquery를 계속 실행 한다.
FROM 에서 1번 서브 쿼리 실행하니까 속도가 빨라진다
group by order by 가 제일 순서가 뒤다
DBMS 가 쿼리를 아 어떻게 어떻게 작성을 해야겠다
근데 DBMS는 천재가 아니라, 어떻게 index 타야 겠다 해도 안 탈 때가 있다
그래서 Plan 이라는건 DBMS가 쿼리 실행 계획을 잡아놓은거다
그걸 조회 할수있는 화면들이 다 있다
DBMS가 멍청해서 index 안탈때 plan을 조회해 보면
full 적어 놓은 부분이 plan에 있으면 full scan 상황인거다
range 라는 부분이 있으면 index를 탄거다
plan 확인해봤는데 full 이 나왔다? 인덱스 못타니까 잘못되있는거
hint?? 강제로 너 plan은 잘못됫으니까 강제로 index를 타라! 지정해주는것
DB서버의 infra 머신들이 아무리 좋아지더라도 쿼리 속도를 올리기위해 리소스 소모량 줄이고 쿼리 짜는게 중요하다 >> INDEX를 태우는 방향으로
HINT도 DBMS마다 차이 있다 PLAN은 지원하는데 HINT는 지원 안하는 DBMS도 있다
SQL 튜닝이 위 얘기다
속도가 안난ㄴ건 거의 대부분 조인 조건에 대한 대상 컬럼이 인덱스가 안잡혀 있거나 아니면 속도가 안나게끔 테이블이 설계가 되어있는경우다
인덱스 1,2 2,1 을 묶는것처럼 내용적으로 중복된 인덱스가 생길수 있다
인덱스 1,2 인애가 생성되있으면 인덱스 1 인애를 만들 필요가 없다
중복 인덱스 생성 XXX , 판단을 해야한다
hint를 줄때 인덱스 명을 줄수있다 그걸 가지고 지시구문이니까 인덱스를 타라! 명령 해라
파티션
하루 100만건 데이터 쓸때
DBA의 2틀간의 심사숙고 >>> 파티션을 쓰자!
원래 쿼리문은 그대로 냅두고
파티션은 내부적으로 가상 테이블을 만든다
가상 테이블을 월단위로해서 만들어주었다
2월달거 조회해볼래?? 전체 테이블 ㄴㄴ 2월 파티션 테이블에서 조회
이렇게 하니까 좀 속도가 났다
튜닝이 진짜 케바케라 몇가지 예시로는 설명이 힘들다
명확한 설명이 힘들다
그떄그때 튜닝 방식이 다르다
특이한 쿼리 얘기
create table a
as selecct * from b
테이블 형태 칼럼 구조 들은 b테이블을 베이스로해서 a 테이블을 만들어라
insert into a
select * from b
b테이블에 ㅣㅇㅆ는 데이터를 다 a 테이블로 복사해넣어라
전제조건은 a, b테이블 구조가 같아야함
구조가 틀리면
insert into a(b, c, d)
select (b, c, d) from b
이렇게 컬럼 지정 해주어라
update select 는 안됨?
delete select 는 안됨?
된다 ㅇㅇㅇ
근데 좀 다르다 insert는 서브쿼리가 아니라서 from 절에 join조건도 해도 되는데
delete select 는 where 조건에 in이 들어가있다
괄호안에 별칭은 괄호 밖에서 사용할 수 없다
in 실제로는 별로 exits랑 별 차이가 없다고 한다
실행 순서는 내가 생각한대로
in은 서브쿼리 안에거를 ㄷ ㅏ조회해서 메인 쿼리 조회 결과랑 비교 하는 거고
exits는 메인 ㅜ커리 조회 결과에 서브 쿼리 조회 결과 를 비교해가는 방식인듯
view
를 쓰는 이유??
보안 성
view는 read only이다
update delete에 적지 못한다
민감한 쿼리를 감추고 싶을때 view를 쓴다
create view longinview 이렇게 쓰는 느낌이다
그다음
select from loginview 이렇게 쓴다
오라클 7때 이제는 안쓰는데 snap shot 이런게 있엇다
view는 실행될때마다 실행되는데 snap shot은 미리 select 해놓은걸 주는 거다
데이터 건수가 어마무시하게 많은 애는 snap shot으로 미리 찍어넣고 썼다
대신 snap shot은 일정 주기로 돌아가다보니 realtime data가 아니었다
snap shot은 죽었다 이런거도 있다~
naming rule
테이블 영문 이름 지정할때 TB_해줘서 지정해주는데
막 TB_userinfo ㅣㅇ렇게
view같은 경우는 통상적으로 적는게 차이가 존재하는데 보통 v_를 표시하곤 했다
seq
테이블에서 pk를 잡기가 애매할때 일련번호를 의미없이 넣기도 한다
트랜잭션이 돌아갈때 동시에 들어가면 막 selctMax 한거 +1 이런게 한명은 오류가 뜰수도 있다
create seqence seqName
{from 0
implement 1
max :100000000(0 13개 억단위)
}
seq.nextval가 오류 안나느넥 둘중 한명이 wating이 걸린다
내부적으로 먼저 보낸애거 보내주고 값 저장했다가 그거를 또 next 하니까 오류가 안생긴다
view랑 seq같이 table이 아닌 db ㅛㅇ소들을 너무 많이 만들면
나중에 운영할때 누락이 될 수 있고
딕셔너리와 도메인
porject 내부 에서
팀별로 테이블 만들때 막 똑같은 값이 들어가야 하는데 테이블 별로
컬럼 생성할때 족ㅁ씩 다른 경우도 생기니까
딕셔너리가 나왔다
회원 user
소숫점금액 fand 뭐 이런식으로 만들었따
얘를 어따 활용 하느냐
회원번호? 무조건 _ 집어 넣는다 규칙
ex 회원금액은 cost_user 이런 식으로
딕셔너리가 규칙을 잡아간다
이것만 가지고 만들면 컬럼 이름이 틀려질수없다
이렇게만 해도 문제점이 발생하는데
데이터 타입하고 length 는 여전히 문제가 생긴다
이떄 나온게 도메인이 나왔다
자주쓰는 컬럼명
회원번호 > varchar(20)
컬럼 정할때 도메인을 보고 컬럼을 선택하는거다
도메인 담당자가 있따
프로젝트 규모가 크던 작던 도메인, 딕셔너리 해야한다
이건 나중에 개발할때도 연계가 되지만, 유지보수할때도 연계가 된다
이런 문세 작성 해야한다.
도메인, 딕셔너리 담당자가 있어야 할듯
