타 커뮤니티 사이트에서 테이블 설계 시 성능 이슈에 관한 글을 보았는데
예전 글이라 현재는 어떨지 모르지만 실제 아래 링크의 내용이 맞는 내용인가요?
제 생각에는 일부 잘못된 내용이 있는 것 같은데 이에 대해 잘 아시는 고수분의 답변을 기다립니다!
링크
http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_Lecture&page=6&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=hit&desc=asc&no=95
Comment 4
-
지영아빠
2022.02.22 09:11
-
구경하는초보
2022.02.22 10:23
답변해주셔서 감사합니다!
큰 데이터 열이 중간에 위치할 경우 사용하지 않는 데이터라도 읽어야 한다라고 설명이 되어있는데
인덱스로 구성된 열만 조회할 경우에도 데이터 페이지를 읽는게 맞는건지 궁금했습니다.
oltp성 테이블(또는 페이징 처리 대상)은 사이즈가 큰 열을 별도의 테이블로 구성하는게 좋을지 고민이 됩니다.
-
이리
2022.02.23 09:55
인덱스로 구성된 열만 SELECT를 하고 WHERE 조건으로 쓰인다면 인덱스 만으로 처리가 됩니다. (nonclustered index를 가정)
이를 커버드 인덱스(Covered Index)라고 하죠.
원 글에서 고정형과 가변형을 고려하지 않은것 같고 유니코드는 2Byte인것도 고려하지 않은 소소한 오류가 보이긴 합니다.
비즈니스 로직에 따라 다르겠지만 한 테이블에 크기가 큰 컬럼이 있고 이를 항상 참조할 필요가 없다면 수직 분할하여 필요할때만 접근하는것이 좋은 설계 일것 같고 항상 참조해야 한다면 굳이 나누어야 하나 라는 생각이 들긴 합니다.
(파일 그룹을 나누어서 파일을 디스크 별로 분산을 시킬수 있다면 도움이 되긴 하겠네요)
간단하게 정리하면 SQL Server에서 한 페이지는 8KB이고 컬럼들 크기가 큰것들이 같이 모여 있다면 불 필요하게 여러개의 페이지를 읽을수 있으니 I/O 최소화를 위해 별도 테이블로 나누면 도움이 될거다 정도가 아닐까 싶네요.
-
구경하는초보
2022.02.23 10:53
답변해주셔서 감사합니다
잘 정리해주신 답변 덕분에 궁금했던 점이 해소되었습니다~
기초적이고 핵심적인 부분을 잘 정리했다고 느껴집니다.
DB에 대한 사랑과 흔히 할 수 있는 실수에 대한 부분을 조목조목 잘 짚어준 듯합니다.
가져오는 데이터량이 상당하게 되면 seek라도 0초라는 보장은 할수 없지만 제일 빠른 방법인건 맞습니다.
무조건 0 이런 부분은 과장이 있긴 합니다. ^^
어떤 내용이 틀렸다고 생각하는 부분일까요?