[SI] 프로젝트 17주차 ~19주차

17주차 ~ 19주차는 오픈 하기전 최종 마무리 단계를 진행했다.

이번주는 마지막으로 검토하면서 문제점을 발견했다.

바로 데이터 검색이였다.

그래서 검색 속도를 높이기 위해 인덱스를 생성하는 작업을 하였다.
하지만 인덱스를 효과적으로 활용하려면 몇 가지 제약 사항이 있다는 것을 알게 되었다.

1. 인덱스 생성 시 고려해야 할 사항

1.1 검색 대상 컬럼의 데이터 타입과 길이 일관성 유지

같은 역할을 하는 컬럼이라도 테이블마다 데이터 타입이 다르면 인덱스 성능이 저하될 수 있음
예를 들어, VARCHAR(255)와 VARCHAR(100)처럼 길이가 다르면 인덱스 활용이 비효율적일 수 있음

1.2 PK(Primary Key)의 순서도 성능에 영향을 줌

PK가 잘못 설정되어 있으면 검색 시 불필요한 정렬이 발생할 수 있음
따라서 적절한 정렬 순서를 유지하도록 테이블을 수정함

2. VARCHAR와 CHAR의 차이점

검색 속도를 고려하다 보니 VARCHAR와 CHAR의 차이점도 정리하게 되었다.

왜냐하면 나는 VARCHAR와 CHAR를 함부로 남발하면서 사용하고 있다는것도 발견했기에... 정리하게됐다.

• VARCHAR는 문자열 길이가 가변적이므로, 필요할 때마다 공간을 동적으로 할당한다.
• CHAR는 고정 길이이기 때문에, 미리 지정된 크기만큼 항상 동일한 공간을 차지한다.
• 일반적으로 검색 속도는 CHAR가 더 빠르지만, 저장 공간은 VARCHAR가 더 효율적이다.

결론: 짧고 자주 검색하는 데이터라면 CHAR, 길이가 일정하지 않은 데이터라면 VARCHAR를 선택하는 것이 좋다.

3. Tibero에서 CHAR → VARCHAR 변환 쿼리

같은 테이블인데도 불구하고 타입을 함부로 사용했기에, 타입을 변경해야하지만
CHAR에서 VARCHAR로 변경하는데는 제약이 있다.

예를 들어, char는 내가 10을 길이로 정했다면, 공백문자로 들어가있기때문에
varchar(10) 로 바꾸기엔 문제가 있었다.
그래서 공백문자를 자르고, varchar 로 바꿔야했다.

마무리
이번 프로젝트에서는 검색 속도를 최적화하면서도
데이터 저장 효율성을 높이기 위해 CHAR → VARCHAR 변환 작업을 진행했다.

• 검색 속도보다는 저장 공간 절약이 중요한 경우, CHAR보다 VARCHAR가 유리하다.
• 동일한 컬럼 역할을 하는 필드는 일관된 데이터 타입을 유지해야 인덱스 최적화가 가능하다.

다음에는 이런일이 발생하지 않도록 주의해야겠다..!!