반응형

지금까지 만들었던 게시판에 사용한 테이블들에 인덱스를 걸어보자.

 

게시판에 등록된 글이 몇 백개 정도라면 인덱스를 걸지 않아도 큰 문제가 없지만 1천개만 넘어가도 화면을 로딩할때 상당한 시간이 걸리게 된다. 

 

이럴때 디비 서버를 확장해 주는 것이 아니고 테이블마다 인덱스를 걸어주면 확연히 속도가 개선된다.

 

인덱스라는것은 영어사전에 표시해두는 a,b,c등의 대표 문자라고 생각하면 된다. 우리가 사전에서 낱말을 찾을때 이런 대표 문자를 사전 옆에 표시해 두지 않으면 하나의 단어를 찾는것도 쉬운 일이 아니게 된다.

 

바로 이런것이 테이블의 인덱스다.

 

인덱스는 보통 where 구문 뒤에 오는 컬럼이나 order by 뒤에 오는 컬럼에 걸어주는 것이 좋다. 하지만 상황에 따라 달라질 수도 있으니 그런것은 나중에 내공이 쌓이고 나면 고민해보도록 하고 지금은 가장 단순한 생각을 가지고 지금까지 만든 테이블에 인덱스를 걸어보도록 하겠다.(늘 얘기하지만 디비는 정답이 없다.)

먼저 board를 보자. where 뒤에 많이 쓰이는 status와 parent_id에 거는 것이 좋을 것 같다. 내말이 정답은 아니므로 참고만 하자.

 

memo 테이블은 board랑 같이 보여지는 테이블이므로 bid와 status에 걸어준다. 이 외에도 bid가 들어가는 테이블들은 모두 bid에 걸어주면 된다. 이런걸 포린키라고 한다. 요즘은 다르게 부르는거 같던데. erd를 그릴때도 중요하다.

 

members는 보통 userid가 조건절에 들어가므로 userid를 걸어준다. passwd는 글자가 길어서 추천하지 않는다. 검색을 위해서라면 email이나 username 걸어줘도 좋다.

 

암튼 이런것이 정답은 아니다. 개발을 20년을 넘게한 나도 인덱스 거는게 어려울때가 있다. 자꾸하다보면 어떻게 거는 것이 좋은지 체득하게 된다. 그때까지 열심히 하자.

 

그런데 정말로 데이터가 많아지면 어떻게 될까? 몇 천만건이되거나 테이블 용량이 몇기가까지 올라간다면? 그렇게 되면 인덱스도 소용없어질때가 온거다. 

 

그래서 요즘은 쇼핑몰엔 거의 필수적으로 검색엔진을 함께 사용한다. 여기 블로그에서도 소개한 적 있는 '엘라스틱서치(elastic search)' 같은 넘들 말이다. 게시판이나 블로그같은 곳에서도 검색 속도 개선을 위해 사용하는 것을 권장한다.

반응형

+ Recent posts