웹마스터 팁
이유는 모르겠는데 뷰테이블을 쓰면 XE의 속도가 크게 떨어지는 것 같습니다.
2011.04.25 13:49
2칸 250줄의 내용을 가진 뷰테이블이 있고
동일한 내용을 저장한 일반 테이블을 사용하여 테스트를 진행해보았습니다.
DB는 파이어버드 2.1버전입니다.
쿼리에 limit는 없었고 전부 다 불러오는 방식이었습니다.
실험 목적으로 한건 아니고 되나 싶어서 했는데 일반 테이블이 보다 빠르게 처리가 끝나더군요.
쿼리 실행한 값을 출력해보니 쿼리 실행 시간은 똑같이 0.001초 이내로 끝났는데
시작과 끝 지점에 microtime함수를 사용하여 시간차이를 체크해보니 뷰를 사용할때는 3.5초 정도. 일반 테이블은 2초 정도 걸렸습니다.
다른 요인들을 하나씩 제거해나가다보니 SQL파서 부분에서 유난히 시간이 늘어나게 되는 것 같습니다만 원인은 전혀 모르겠고 코어는 아직 이해도 못해서 잘 모르겠습니다.
결론은 뷰보다는 일반 테이블을 사용하는게 좋겠습니다.
동일한 내용을 저장한 일반 테이블을 사용하여 테스트를 진행해보았습니다.
DB는 파이어버드 2.1버전입니다.
쿼리에 limit는 없었고 전부 다 불러오는 방식이었습니다.
실험 목적으로 한건 아니고 되나 싶어서 했는데 일반 테이블이 보다 빠르게 처리가 끝나더군요.
쿼리 실행한 값을 출력해보니 쿼리 실행 시간은 똑같이 0.001초 이내로 끝났는데
시작과 끝 지점에 microtime함수를 사용하여 시간차이를 체크해보니 뷰를 사용할때는 3.5초 정도. 일반 테이블은 2초 정도 걸렸습니다.
다른 요인들을 하나씩 제거해나가다보니 SQL파서 부분에서 유난히 시간이 늘어나게 되는 것 같습니다만 원인은 전혀 모르겠고 코어는 아직 이해도 못해서 잘 모르겠습니다.
결론은 뷰보다는 일반 테이블을 사용하는게 좋겠습니다.
댓글 2
-
SMaker
2011.04.25 20:32
-
마일드^^
2011.04.26 09:30
아마 말씀주신게 create view as xxxx 한 이 DB Object 에서 의 view 를 말씀하시는것 같군요.
당연하죠 view 는 인덱스 태우기가 힘들어요.
mysql 에서의 view 는 미완성작에 가깝죠,
mssql 이라면 모를까 .
속도 튜닝은 캐싱 알고리즘을 잘잡으면 db 튜닝이 좀 덜되두 많은 부분 보완할수있어요.
무슨 팁인지 모르겠습니다.