본문 바로가기
정보관리(데이터베이스, DB)/DB

인덱스 튜닝 방법

by 3604 2025. 9. 25.
728x90

데이터베이스 서버 저장공간이 400GiB이고 tibero를 설치했고, 데이터베이스는 인덱스 공간과 데이터 공간으로 분리하여 설치했으나 인덱스 용량이 늘어나면서 데이터 공간을 초과하고 있어 인덱스 공간을 정리하고 싶고 가능하면 인덱스를 튜닝하고 싶은데 방법은?
 
TIBCO IndexSpace Cleanup Method
현재 상황을 정리하면:
  • 총 저장공간: 400 GiB
  • 데이터 공간과 인덱스 공간을 분리하여 설치
  • 인덱스 공간이 계속 증가하면서 데이터 공간을 압박
  • 인덱스 공간 정리 및 튜닝 필요

✅ 1. 인덱스 공간이 왜 계속 증가할까?

  •  
  • INSERT 시마다 인덱스 엔트리가 1:1로 증가
  • UPDATE 시 기존 인덱스 엔트리 삭제 + 새 엔트리 삽입
  • **DELETE 시 인덱스 엔트리는 삭제되지만, 블록 내부 공간은 재사용되지 않고 빈 공간(Fragmentation)으로 남음
  • → 결국 인덱스 세그먼트는 계속 커지고, 실제 데이터보다 더 많은 공간을 차지할 수 있음

✅ 2. 인덱스 공간 정리 방법 (Tibero 기준)

🔧 1) 불필요한 인덱스 제거

 

-- 사용하지 않는 인덱스 찾기 (Oracle 호환 쿼리)
SELECT INDEX_NAME, TABLE_NAME
FROM ALL_INDEXES --USER_INDEXES
WHERE INDEX_NAME NOT IN (
    SELECT INDEX_NAME
    FROM USER_IND_COLUMNS
    WHERE COLUMN_NAME IN (
        SELECT COLUMN_NAME
        FROM USER_CONS_COLUMNS
        WHERE CONSTRAINT_NAME IN (
            SELECT CONSTRAINT_NAME
            FROM USER_CONSTRAINTS
            WHERE CONSTRAINT_TYPE IN ('P', 'U')
        )
    )
);

  •  
  • 외부에서 생성한 테스트 인덱스, 중복 인덱스, 오래된 인덱스 등 삭제 가능

🔧 2) 인덱스 리빌드 (Rebuild)

  •  
  • ** fragmentation 제거 및 공간 회수**
 
ALTER INDEX [인덱스명] REBUILD ONLINE;
  • ONLINE 옵션은 Tibero에서도 지원하며, 락 없이 재구성 가능
  • 리빌드 후 세그먼트 크기 감소 가능 (실제 공간 회소)

🔧 3) 인덱스 압축 (Key Compression)

  • 반복되는 키 값이 많은 인덱스에 유용
 
ALTER INDEX [인덱스명] REBUILD COMPRESS 1;
  • Tibero는 Oracle 호환 모드에서 COMPRESS 지원
  • 리프 블록당 저장 가능한 엔트리 수 증가 → 세그먼트 크기 감소

🔧 4) 테이블 파티셔닝 + 로컬 인덱스

  • 대용량 테이블의 경우 파티셔닝 후 로컬 인덱스 사용
  • 오래된 파티션은 DROP 또는 TRUNCATE로 인덱스도 함께 삭제
  • → 인덱스 공간 일괄 회수 가능

✅ 3. 즉각 실천 가능한 체크리스트

Table
 
단계작업효과
1 USER_INDEXES에서 미사용 인덱스 식별 후 삭제 공간 즉시 회수
2 핫 테이블의 인덱스 리빌드 (ALTER INDEX ... REBUILD ONLINE) fragmentation 제거, 용량 ↓
3 반복 키가 많은 인덱스에 COMPRESS 1 적용 리프 블록 압축, 용량 ↓
4 파티션 테이블로 전환 후 로컬 인덱스 사용 오래된 데이터·인덱스 일괄 삭제 가능

✅ 4. 마무리 조언

  • 리빌드 전후로 DBA_SEGMENTS에서 바이트 크기 비교 → 실제 효과 확인
  • 정기적으로 인덱스 리빌드 스크립트 스케줄링 (예: 주 1회)
  • 모든 작업은 운영 시간 외에 수행 권장 (리빌드 시 CPU/IO 부하 발생 가능)

✅ 요약 한 줄

불필요한 인덱스는 삭제하고, 나머지는 REBUILD 또는 COMPRESS로 용량을 줄이며, 대용량 테이블은 파티셔닝+로컬인덱스로 장기적으로 관리하세요.

 

 

외부에서 생성한 테스트 인덱스, 중복 인덱스, 오래된 인덱스 등 삭제 가능 인덱스 전체와 조회하는 쿼리?
 
 
아래는 Tibero(Oracle 호환) 에서
“삭제해도 안전한” 인덱스를 **한 번에 전부 찾는 쿼리”입니다.
(1) 중복 인덱스, (2) 외부 테스트 인덱스, (3) 최근 90일간 사용되지 않은 인덱스를 모두 추출합니다.
  1. 90일 이상 사용되지 않은 인덱스
Tibero는 Oracle처럼 V$OBJECT_USAGE 뷰를 제공합니다.
모니터링을 먼저 켜야 통계가 쌓입니다.
sql
 
-- 1. 모니터링 걸기 (한 번만 실행)
ALTER INDEX [owner].[index_name] MONITORING USAGE;

-- 2. 90일 이상 한 번도 안 쓴 인덱스 리스트
SELECT u.index_name, u.table_name, i.last_analyzed
FROM   user_object_usage u
JOIN   user_indexes      i ON i.index_name = u.index_name
WHERE  u.used = 'NO'
AND    i.last_analyzed < SYSDATE - 90;
  1. 중복 인덱스 (완전히 같은 컬럼·순서)
sql
 
WITH cols AS (
    SELECT index_name,
           LISTAGG(column_name, ',') WITHIN GROUP (ORDER BY column_position) AS col_list
    FROM   user_ind_columns
    GROUP BY index_name
)
SELECT a.index_name AS idx1,
       b.index_name AS idx2,
       a.col_list
FROM   cols a
JOIN   cols b
  ON  a.col_list = b.col_list
 AND  a.index_name < b.index_name;
  1. PK / UK 제약이 아닌 일반 인덱스 전체
sql
 
SELECT index_name, table_name, uniqueness
FROM   user_indexes
WHERE  index_name NOT IN (
        SELECT index_name
        FROM   user_constraints c
        JOIN   user_indexes     i
               ON i.index_name = c.index_name
        WHERE  c.constraint_type IN ('P','U')
      )
ORDER BY table_name, index_name;
  1. 한방 쿼리로 “삭제 후보” 전체 추출
위 3개 결과를 UNION 하면 됩니다.
아래는 하나의 뷰처럼 쓸 수 있는 통합 쿼리:
sql
 
/* 삭제 안전 후보 인덱스 통합 리스트 */
SELECT DISTINCT
       i.index_name,
       i.table_name,
       CASE
         WHEN u.index_name IS NOT NULL THEN 'UNUSED_90DAYS'
         WHEN d.idx2        IS NOT NULL THEN 'DUPLICATE_WITH_'||d.idx2
         ELSE 'NOT_CONSTRAINT'
       END AS reason
FROM   user_indexes i
LEFT JOIN user_object_usage u
       ON u.index_name = i.index_name AND u.used = 'NO'
LEFT JOIN (
        /* 중복 인덱스 이름 한쪽만 뽑기 */
        WITH cols AS (
            SELECT index_name,
                   LISTAGG(column_name, ',') WITHIN GROUP (ORDER BY column_position) AS col_list
            FROM   user_ind_columns
            GROUP BY index_name
        )
        SELECT a.index_name AS idx1, b.index_name AS idx2
        FROM   cols a
        JOIN   cols b
          ON  a.col_list = b.col_list
         AND  a.index_name < b.index_name
) d ON d.idx1 = i.index_name
WHERE  i.index_name NOT IN (
        SELECT index_name
        FROM   user_constraints c
        JOIN   user_indexes     i ON i.index_name = c.index_name
        WHERE  c.constraint_type IN ('P','U')
      )
ORDER BY table_name, index_name;
  1. 삭제 전 확인 체크리스트
  1. 백업 또는 DDL 스크립트 저장
    sql
    DBMS_METADATA.GET_DDL('INDEX','INDEX_NAME','OWNER')
  2. 개발/테스트 환경에서 먼저 삭제 후 애플리케이션 정상 동작 확인
  3. 삭제
    sql
    DROP INDEX [owner].[index_name];

요약

위 통합 쿼리 한 방으로
“PK/UK 아니면서 90일간 안 쓰였거나 중복된” 인덱스를 한눈에 보고
DROP INDEX 로 안전하게 정리하면 됩니다.
 
 
 
USER_INDEXES에서 미사용 인덱스 식별 후 삭제하는 방법
 
 
USER_INDEXES만으로는 **“실제 사용 여부”**를 알 수 없습니다.
USER_INDEXES에는 인덱스의 정의만 있고, 최근 접근 이력은 없기 때문입니다.
따라서 아래 2-단계 절차를 따라야 **“안심하고 DROP”**할 수 있습니다.

1단계 : 사용 여부 모니터링 걸기 (필수!)

모니터링을 걸지 않으면 USED='NO'가 전혀 나오지 않습니다.
sql
-- 한 번에 모든 일반 인덱스에 모니터링 걸기
BEGIN
  FOR r IN (SELECT index_name FROM user_indexes) LOOP
    EXECUTE IMMEDIATE 'ALTER INDEX '||r.index_name||' MONITORING USAGE';
  END LOOP;
END;
/

2단계 : 모니터링 결과로 미사용 인덱스 찾기

최소 한 달~두 달 운영 후 아래 쿼리로 한 번도 안 쓴 인덱스 리스트 확보
sql
SELECT u.index_name,
       i.table_name,
       i.last_analyzed
FROM   user_object_usage u
JOIN   user_indexes      i ON i.index_name = u.index_name
WHERE  u.used = 'NO'          -- 한 번도 안 쓰임
AND    i.index_name NOT IN (  -- PK/UK 제약 인덱스는 제외
        SELECT index_name
        FROM   user_constraints c
        WHERE  c.constraint_type IN ('P','U')
          AND  c.index_name = i.index_name);

3단계 : 삭제 전 확인 & 삭제

  1. DDL 백업
    sql
    SELECT DBMS_METADATA.GET_DDL('INDEX', index_name) AS ddl
FROM   user_indexes
WHERE  index_name = '대상인덱스';
  2. 테스트 서버에서 DROP 후 애플리케이션 정상 동작 확인
  3. 운영 서버에서 삭제
    sql
    DROP INDEX 대상인덱스;

한방에 정리하는 “safe-drop” 스크립트

sql
/* 현재 연결 계정의 미사용 일반 인덱스를 모두 DROP 하는 생성 스크립트 */
SELECT 'DROP INDEX ' || index_name || ';' AS drop_ddl
FROM   user_object_usage u
JOIN   user_indexes i ON i.index_name = u.index_name
WHERE  u.used = 'NO'
AND    NOT EXISTS (
        SELECT 1
        FROM   user_constraints c
        WHERE  c.index_name = i.index_name
          AND  c.constraint_type IN ('P','U')
);
출력된 drop_ddl을 그대로 실행하면 미사용+비필수 인덱스만 일괄 삭제됩니다.

요약

USER_INDEXES 단독으로는 미사용 여부를 판단할 수 없습니다.
반드시
  1. ALTER INDEX … MONITORING USAGE 로 모니터링 →
  2. USER_OBJECT_USAGE.USED='NO' 로 미사용 인덱스를 확인 →
  3. PK/UK 제약 인덱스는 제외하고 DROP 하세요.
Copy
Share
 
 
핫 테이블의 인덱스 리빌드 방법
Copy
Share
 
Tibero에서 핫 테이블(=DML이 빈번한 테이블) 의 인덱스를
락-프리, 24×7 운영 중에도 리빌드 하려면 아래 3-단계를 따르세요.

1단계 : 리빌드 대상 인덱스 확인

sql
-- 세그먼트 크기 TOP 10 + 최근 7일 DML이 많은 테이블의 인덱스
SELECT i.index_name,
       i.table_name,
       s.bytes/1024/1024 AS mb,
       i.last_analyzed
FROM   user_indexes i
JOIN   user_segments s ON s.segment_name = i.index_name
WHERE  i.table_name IN (
        SELECT table_name
        FROM   user_tab_modifications
        WHERE  timestamp > SYSDATE - 7)
ORDER BY s.bytes DESC
FETCH FIRST 10 ROWS ONLY;

2단계 : ONLINE 리빌드 수행 (락 없음)

Tibero는 Oracle 문법 그대로 지원합니다.
sql
ALTER INDEX 인덱스명 REBUILD
  ONLINE              -- 테이블 락 발생 안 함
  PARALLEL 4          -- CPU 코어 수에 맞춰 조절
  TABLESPACE 인덱스_테이블스페이스
  STORAGE (INITIAL 1M NEXT 1M)
  COMPRESS 1          -- 반복 키 많을 때만
  NOLOGGING;          -- 로그 최소화 (백업 고려 후 사용)
옵션 설명
  • ONLINE : DML 차단 없이 재구성
  • PARALLEL : 리빌드 시간 단축 (리빌드 끝나면 ALTER INDEX … NOPARALLEL 권장)
  • NOLOGGING : 재해 복구(RMAN) 환경이 아니면 가능 (로그 양 ↓, 속도 ↑)

3단계 : 리빌드 후 검증 & 통계 갱신

sql
-- 세그먼트 크기 감소 확인
SELECT segment_name, bytes/1024/1024 AS mb
FROM   user_segments
WHERE  segment_name = '인덱스명';

-- 인덱스 상태 확인
SELECT index_name, status, partitioned
FROM   user_indexes
WHERE  index_name = '인덱스명';   -- STATUS='VALID' 여야 함

-- 통계 재수집 (옵티마이저 정보 최신화)
EXEC DBMS_STATS.GATHER_INDEX_STATS(ownname => USER, indname => '인덱스명');

한방에 끝내는 “핫 인덱스 리빌드” 프로시저

sql
CREATE OR REPLACE PROCEDURE rebuild_hot_indexes IS
BEGIN
  FOR r IN (SELECT index_name FROM user_indexes WHERE status = 'VALID') LOOP
    EXECUTE IMMEDIATE
      'ALTER INDEX '||r.index_name||' REBUILD ONLINE PARALLEL 4 NOLOGGING';
    EXECUTE IMMEDIATE
      'ALTER INDEX '||r.index_name||' NOPARALLEL';
    DBMS_STATS.GATHER_INDEX_STATS(ownname => USER, indname => r.index_name);
  END LOOP;
END;
/

체크 포인트

  1. 리빌드 중에도 DML 차단 없음 → ONLINE 키워드 필수
  2. 리빌드 끝나면 반드시 NOPARALLEL 로 원복 (평시 쿼리 계획 오류 방지)
  3. RMAN 백업 정책 있으면 NOLOGGING 금지 (복구 불가 세그먼트 됨)
  4. 스페어 공간 1.2× 확보 → 리빌드 중 임시 세그먼트 필요

요약

ALTER INDEX … REBUILD ONLINE 한 줄이 핵심이며,
PARALLEL + NOLOGGING 으로 서비스 중단 없이 fragmentation 제거 및 공간 회수 완료.
Copy
Share
 
 
반복 키가 많은 인덱스에 COMPRESS 적용 방법?
 
 
Tibero(Oracle 호환 모드)에서 반복되는 키 값이 많은 인덱스를
COMPRESS 하면 리프 블록당 압축률 ↑ → 세그먼트 크기 ↓ → 버퍼 히트율 ↑
아래 3-단계만 따르세요.

1단계 : 압축 전 크기 & 중복도 확인

sql
 
-- 인덱스 세그먼트 크기
SELECT bytes/1024/1024 AS mb
FROM   user_segments
WHERE  segment_name = '대상인덱스';

-- 리프 블록당 평균 엔트리 수 (중복도 대략 확인)
SELECT
       blevel                       +1 AS height,
       leaf_blocks,
       distinct_keys,
       ROUND(leaf_blocks/distinct_keys,1) AS avg_rows_per_key
FROM   user_indexes
WHERE  index_name = '대상인덱스';

-- avg_rows_per_key ≥ 10 이상이면 압축 효과 큼

2단계 : COMPRESS 1 (기본) 로 ONLINE 리빌드

sql
 
ALTER INDEX 대상인덱스
  REBUILD
  ONLINE
  COMPRESS 1                -- prefix column 1개 압축
  PARALLEL 4
  TABLESPACE 인덱스_테이블스페이스
  NOLOGGING;                -- 백업 정책 허용 시만
COMPRESS 옵션
  • COMPRESS 1 : 인덱스 첫 번째 컬럼 값을 prefix로 압축 (가장 일반적)
  • COMPRESS 2 : 앞 2개 컬럼을 prefix (두 번째 컬럼도 반복 많을 때)
  • COMPRESS 3 … 최대 인덱스 컬럼 수까지 가능 (테스트 후 결정)

3단계 : 압축 후 결과 확인

sql
 
-- 세그먼트 크기 비교
SELECT segment_name, bytes/1024/1024 AS mb
FROM   user_segments
WHERE  segment_name = '대상인덱스';

-- 압축 통계
SELECT index_name, prefix_length, compression
FROM   user_indexes
WHERE  index_name = '대상인덱스';
/* PREFIX_LENGTH = 실제 압축에 사용된 컬럼 수 */

한방에 끝내는 프로시저 예시

sql
 
CREATE OR REPLACE PROCEDURE compress_index
  (p_idx IN VARCHAR2, p_prefix IN PLS_INTEGER DEFAULT 1)
IS
BEGIN
  EXECUTE IMMEDIATE
    'ALTER INDEX '||p_idx||
    ' REBUILD ONLINE COMPRESS '||p_prefix||' NOLOGGING PARALLEL 4';
  EXECUTE IMMEDIATE 'ALTER INDEX '||p_idx||' NOPARALLEL';
  DBMS_STATS.GATHER_INDEX_STATS(USER, p_idx);
END;
/

-- 실행
EXEC compress_index('대상인덱스', 1);

주의사항

  1. 압축 컬럼 수(prefix)는 실제 중복도에 따라 결정
    • COMPRESS 1 로도 30~50 % 감소 흔함
    • prefix 수 ↑ → CPU ↑, 압축률 ↑ ( diminishing return 존재)
  2. 무조건 큰 인덱스가 압축에 유리한 건 아님 → 반복 키 많을 때만 유효
  3. PK/UK 인덱스도 압축 가능 (제약 삭제 없이 REBUILD 만 하면 됨)
  4. OLTP 고부하 시간대보다는 Batch 유지보수 시간대에 수행 권장

요약

ALTER INDEX … REBUILD ONLINE COMPRESS 1;
한 줄로 리프 블록 prefix 압축 적용 → 중복 키 많을 때 용량 30~70 %↓ ,
I/O ↓, 버퍼 캐시 효율 ↑, Full-Scan·Range-Scan 성능 ↑
 
 
 
파티션 테이블로 전환 후 로컬 인덱스 사용 방법?
 
 
 
Tibero and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat and Tiberiat
아래는 기존 비-파티션 테이블을 파티션 테이블로 전환하고,
그와 함께 로컬 인덱스(Local Index) 를 만들어 오래된 파티션‧인덱스를 한꺼번에 DROP할 수 있도록
Tibero(Oracle 호환) 기준으로 단계별로 정리한 실전 가이드입니다.
  1. 준비 : 파티션 전략 & 스키마 백업
  1. 파티션키 선정 (날짜, PK 범위 등)
    예) CREATE_DATE 컬럼을 기준으로 월별 RANGE 파티션
  2. TBSQL 로 DDL 추출 → 백업
    sql
    SELECT DBMS_METADATA.GET_DDL('TABLE','EMP') FROM dual;
SELECT DBMS_METADATA.GET_DDL('INDEX','EMP_PK') FROM dual;
  1. 파티션 테이블 생성 (기존 구조 복제 + 파티션 정의)
sql
 
CREATE TABLE emp_part (
    emp_id      NUMBER,
    emp_name    VARCHAR2(100),
    create_date DATE,
    CONSTRAINT emp_part_pk PRIMARY KEY (emp_id, create_date)
)
PARTITION BY RANGE (create_date)
INTERVAL (NUMTOYMINTERVAL(1,'MONTH'))
( PARTITION p_old VALUES LESS THAN (DATE'2020-01-01') )
;
  • INTERVAL 을 쓰면 신규 월이 자동 파티션 생성
  • PK 반드시 파티션키 포함 (Tibero 제약)
  1. 데이터 이전 (온라인-비중단 방식)
1) 병행 INSERT (추천)
sql
 
INSERT /*+ APPEND PARALLEL(8) */ INTO emp_part
SELECT * FROM emp;
COMMIT;
2) DBMS_REDEFINITION 사용 (24×7 허용) Tibero 7↑ 에서는 DBMS_REDEFINITION.START_REDEF_TABLE 지원
(Oracle 과 동일 문법)
  1. 로컬 인덱스(Local Index) 생성
1) PK는 이미 테이블 생성 시 LOCAL 로 자동 생성
2) 추가 보조 인덱스도 LOCAL 로
sql
Copy
CREATE INDEX emp_part_idx1 ON emp_part (dept_id)
LOCAL                 -- ★ 파티션마다 독립 INDEX 세그먼트
COMPRESS 1            -- 반복 키 많으면 압축
ONLINE
PARALLEL 4;
  • LOCAL 을 빼면 글로벌 인덱스 → 파티션 DROP 시 무효화(INVALID) 되므로 주의!
  1. 인덱스‧파티션 일괄 DROP (공간 회수)
1) 오래된 파티션 + 로컬 인덱스 동시 삭제
sql
Copy
ALTER TABLE emp_part DROP PARTITION p_old
UPDATE INDEXES;   -- LOCAL 이므로 자동 유효
  • UPDATE INDEXES 는 글로벌 인덱스 유지용이나, 로컬 인덱스는 함께 삭제되므로 별도 정리 필요 없음
2) 자동 Interval 파티션 1개월 이상 보관 후 삭제 예시
sql
Copy
-- 6개월 지난 파티션 목록
SELECT partition_name, high_value
FROM   user_tab_partitions
WHERE  table_name = 'EMP_PART'
AND    partition_position <=
       (SELECT MAX(partition_position)-6 FROM user_tab_partitions WHERE table_name='EMP_PART');

-- 동적 DROP 스크립트 생성
SELECT 'ALTER TABLE emp_part DROP PARTITION '||partition_name||';' AS ddl
FROM   user_tab_partitions
WHERE  table_name = 'EMP_PART'
AND    partition_position <=
       (SELECT MAX(partition_position)-6 FROM user_tab_partitions WHERE table_name='EMP_PART');
생성된 ddl 을 그대로 실행 → 파티션+로컬인덱스 한꺼번 삭제 → 공간 즉시 회수
  1. 검증 & 통계
sql
Copy
-- 세그먼트 크기 비교
SELECT segment_name, partition_name, bytes/1024/1024 AS mb
FROM   user_segments
WHERE  segment_name = 'EMP_PART';

-- 인덱스 상태 확인
SELECT index_name, partition_name, status
FROM   user_ind_partitions
WHERE  index_name LIKE 'EMP_PART%';
-- STATUS = USABLE 이어야 함
  1. 유지보수 자동화 팁
  • 파티션 자동 생성 : INTERVAL 로 해결
  • 파티션 자동 삭제 :
    • Linux crontab + 위 동적 DROP 스크립트
    • 또는 Tibero Job Scheduler (DBMS_SCHEDULER) 에 등록

요약

  1. PARTITION BY RANGE … INTERVAL 로 월별 자동 파티션 테이블 생성
  2. PK 포함 → LOCAL 인덱스 자동 생성
  3. 보조 인덱스도 CREATE INDEX … LOCAL 로 생성
  4. ALTER TABLE … DROP PARTITION p_old 한 방에 파티션+로컬인덱스 삭제
  5. 글로벌 인덱스 없음 → INVALID 우려 없이 실시간 공간 회수 가능
728x90
저작자표시 비영리 변경금지 (새창열림)

'정보관리(데이터베이스, DB) > DB' 카테고리의 다른 글

내부 조인 제거(Inner-Join Elimination) 란?  (0) 2025.09.25
외부에서 생성한 테스트 인덱스, 중복 인덱스, 오래된 인덱스 등 삭제 가능 인덱스 전체 조회 쿼리  (0) 2025.09.25
tibero에서 데이터를 많이 저장할 수록 왜 인덱스가 증가할까? 조회한 인덱스를 계속 저장하나?  (0) 2025.09.25
DB에서 인덱스 생성 시 고려 사항  (0) 2025.09.25
db에서 중복 exploding  (0) 2025.09.25

관련글

티스토리툴바