Backend 개발/SQL 성능 개선
쿼리 튜닝을 한다고 인덱스(Index)를 마구 설정하면 어떻게 될까?
수달리즘
2025. 4. 16. 11:25
반응형
인덱스를 무식하게 많이 걸면 어떻게 될까?
- 인덱스를 많이 걸면 조회 성능은 향상되지만, 기회 비용이 발생한다.
→ 쓰기 작업(삽입, 수정, 삭제) 성능이 저하됨 - 인덱스를 추가한다는 건 인덱스용 테이블이 추가적으로 생성된다는 뜻이다. 그렇다면 인덱스를 추가하지 않은 상태에서 원래 테이블에만 데이터를 넣는 것보다 인덱스를 추가한 상태에서 원래 테이블과 인덱스용 테이블 둘 다에 데이터를 넣어야 하는게 더 느릴 수밖에 없다.
인덱스의 개수가 많아지면 많아질수록 성능은 느려질 수밖에 없다. 데이터를 삽입하는 것 이외에도 수정, 삭제 작업에서도 같은 이유로 성능이 느려진다.
따라서 최소한의 인덱스만 설정해야 한다는 것을 유념해야 한다!
인덱스 많이 설정했을 경우 성능 측정 예제
MariaDB에서 모든 컬럼에 인덱스를 설정하고 10만개의 데이터를 INSERT 해본다.
CREATE TABLE test_table_many_index (
id INT AUTO_INCREMENT PRIMARY KEY,
COLUMN1 INT,
COLUMN2 INT,
COLUMN3 INT,
COLUMN4 INT,
COLUMN5 INT,
COLUMN6 INT,
COLUMN7 INT,
COLUMN8 INT,
COLUMN9 INT,
COLUMN10 INT
);
-- test_table_many_index 테이블의 모든 컬럼에 인덱스 추가
CREATE INDEX idx_column1 ON test_table_many_index (COLUMN1);
CREATE INDEX idx_column2 ON test_table_many_index (COLUMN2);
CREATE INDEX idx_column3 ON test_table_many_index (COLUMN3);
CREATE INDEX idx_column4 ON test_table_many_index (COLUMN4);
CREATE INDEX idx_column5 ON test_table_many_index (COLUMN5);
CREATE INDEX idx_column6 ON test_table_many_index (COLUMN6);
CREATE INDEX idx_column7 ON test_table_many_index (COLUMN7);
CREATE INDEX idx_column8 ON test_table_many_index (COLUMN8);
CREATE INDEX idx_column9 ON test_table_many_index (COLUMN9);
CREATE INDEX idx_column10 ON test_table_many_index (COLUMN10);
-- 10만개 데이터 INSERT
INSERT INTO test_table_many_index (COLUMN1, COLUMN2, COLUMN3, COLUMN4, COLUMN5, COLUMN6, COLUMN7, COLUMN8, COLUMN9, COLUMN10)
WITH recursive cte AS (
SELECT 1 AS n UNION ALL SELECT n+1 FROM cte WHERE n < 100000
)
SELECT
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000),
FLOOR(RAND() * 1000)
FROM cte;
해당 INSERT 쿼리를 여러 번 실행하면 10.672~13.093초가 걸린다. 앞선 예제에 비해 5~6배가 넘는 시간이 걸린다 😮
인덱스를 추가하면 조회 속도는 빨라질 수 있으나 쓰기 속도는 느려진다는 것을 반드시 기억해야 한다!
728x90
반응형