내가 어디서 봤는지는 모르겠는데..
그때 강사가 그랬거든.
정규화 시킨다고 테이블 나눠놓으면
현장에서 사람들이 조인하면 느리다고 반발하는데
그건 오해다.
조인한다고 느려지는 거 아니다.
그러면서
이러저러한 상황이면 조인해서 느려지는 경우가 있다
그렇게 부연설명 해줬는데
그게 무슨 과목인지
어떤 강의인지
그런 게 생각이 안나서..
다시 찾아보지를 못하고 있음.
내가 지금 찾고 싶은 건
'조인해서 느려지는 상황'을 찾고 싶은데
못 찾겠어......
ㅡ_ㅡ;
그때 강사가 그랬거든.
정규화 시킨다고 테이블 나눠놓으면
현장에서 사람들이 조인하면 느리다고 반발하는데
그건 오해다.
조인한다고 느려지는 거 아니다.
그러면서
이러저러한 상황이면 조인해서 느려지는 경우가 있다
그렇게 부연설명 해줬는데
그게 무슨 과목인지
어떤 강의인지
그런 게 생각이 안나서..
다시 찾아보지를 못하고 있음.
내가 지금 찾고 싶은 건
'조인해서 느려지는 상황'을 찾고 싶은데
못 찾겠어......
ㅡ_ㅡ;
조인하려면 nested나 hash나 결국 연산을 해야하잖아. 반정규보다 정규화 해서 조인하는 게 더 느려지는 거 아닌가
근데 만일 RDBMS같이 클러스터가 아니면 반정규가 더 느릴수 있음. where절로 찾으려면 메모리에 올려야 하는데 테이블 전체 크기가 매우 크면 I/O시간에다 기존 캐싱을 위해 버퍼캐시에 버퍼캐시가 부족해질 수 있거나 버퍼가 자주 update됨 따라서 join을 사용하면 nested를 예로 들때 선행 테이블이 작으면 연산양을 많이 줄일 수 있겠지
프롬 절에 테이블 한개 넣든 두개 넣든 속도 차이가 안 납니다. 근데 이러저러한 경우에는 조인해서 느려지는 경우가 있습니다. 그런 수업이었는데.. 그때 들은 이런저런 상황이 ㅇㄹㅇ형이 말해준 저 상황 맞는 거 같음.. 설명 감사감사합니다
그럼 다행이고, 주저리주저리 말이 길었는데 결론은 상황에 따라 다른거 같고. 조인이 느린 경우는 그냥 Disk I/O로 빼와서 메모리에 올리는 작업 뿐 아닌 Join 연산이 필요하니까고 조인이 빠른 경우는 테이블이 워낙 크면 메모리 올리는 과정에서 문제가 될 수 있다. 꼭 빠르다 느리다 정답은 없다고 생각함.
조인하는 테이블에 인덱스 안걸려있으면 느려지지 풀스캔하는경우
뜬금없지만 헬마횽 이럴 때 툭툭 한마디씩 하시는 거 보면 되게 멋있어요.. 제 사수였음 좋겠다능...
레알 빈말이 아니라.. 맨날 뻘글 쓰시는 거 같으면서도 저같은 쩌리들이 궁금해하는 글 올리면 스윽 와서 알려주고 가시는 게 되게 멋있어요....!
현직 dba고 거의 튜너인데 조인하기 때문에 느려지는게 아니고 실행계획 보고 판단해야지 조인컬럼 인덱스 안걸려있거나 함수 사용/ 묵시적 형변환 되는 경우, 조인하는데 옵티마이저가 혼란이 오게 만드는 경우(대부분은 쿼리 잘못 짜서)
변명 같지만... 쿼리를 잘 짜는 게 어려워요... ㅜㅜ
조인컬럼에 인덱스 필수로 태우는 거 유념하겠습니다
함수 사용 그 자체로 성능이 느려지나요? 함수나 형변환같은 거 자체가 아니라 이를 통해 인덱스를 못타게 되서 느리게 되는 거죠?
케바케임 필터링 조건이 있고 거기서 필터링 많이 되면 조인컬럼에 인덱스 없어도 크게 차이 안나는 경우가 좀 있는데 필터링 많이 안되고 조인컬럼이 그 테이블에서 선택도가 매우 좋은 컬럼인데 인덱스 없으면 성능상 좀 치명적임 근데 어차피 개발자가 쿼리 잘 짜는거 크게 기대안함 그거 검수하고 튜닝해주는게 우리 일이라 생각해서 ㅇㅇ
함수나 형변환 자체가 문제가 아니라 인덱스 못타는게 문제임 형변환도 후행 테이블의 컬럼이 데이터 타입 우선순위가 높으면 조인할때 형변환 되어도 선행 테이블 컬럼에서 형변환 되기때문에 조인에 문제없어