InnoDB 테이블스페이스 구조: system, file-per-table, general tablespace

1. 왜 테이블스페이스 구조를 이해해야 하는가

InnoDB를 운영하다 보면 데이터 파일의 크기, 테이블 이동, 백업 용량, 디스크 증설, DDL 수행 시간, 장애 복구 시간 같은 문제가 모두 “어떤 tablespace에 무엇이 저장되는가”로 이어진다. SQL 계층에서 테이블은 schema.table이라는 논리 객체로 보이지만, InnoDB 내부에서는 clustered index, secondary index, undo 정보, 데이터 딕셔너리, temporary object, doublewrite 관련 영역 등이 여러 tablespace와 파일로 나뉘어 저장된다.

테이블스페이스 구조를 모르면 다음과 같은 운영 판단을 잘못 내리기 쉽다.

DROP TABLE을 했는데 디스크가 왜 즉시 줄지 않는지 오해한다.
ibdata1 파일이 커졌을 때 온라인으로 줄일 수 있다고 착각한다.
innodb_file_per_table을 끄거나 켜는 변경이 기존 테이블까지 자동 재배치한다고 생각한다.
여러 테이블을 general tablespace에 묶었을 때 백업, 이동, 공간 반환 특성이 어떻게 바뀌는지 간과한다.
Aurora MySQL에서 로컬 파일 경로 기준의 판단을 그대로 적용한다.

이 글은 InnoDB 테이블스페이스를 system tablespace, file-per-table tablespace, general tablespace 중심으로 설명한다. 대상은 MySQL 8.0 이상이며, 가능하면 MySQL 8.4 LTS에서도 통하는 운영 원칙을 기준으로 한다.

2. InnoDB tablespace의 기본 개념

Tablespace는 InnoDB가 page를 저장하는 논리적 저장 공간이다. InnoDB의 기본 page size는 일반적으로 16KB이며, 테이블과 인덱스는 page 단위로 배치된다. 여러 page는 extent 단위로 관리되고, extent는 다시 segment에 할당된다. 사용자는 SQL에서 row와 index를 다루지만, InnoDB는 내부적으로 page, extent, segment, tablespace 계층으로 공간을 관리한다.

단순화하면 관계는 다음과 같다.

테이블/인덱스
  -> segment
    -> extent
      -> page
        -> tablespace file

InnoDB에서 tablespace는 단순히 “파일 하나”라는 의미가 아니다. tablespace는 내부 식별자와 메타데이터를 가지며, 실제 파일은 하나 또는 여러 개일 수 있다. MySQL 8.0 이후에는 데이터 딕셔너리가 InnoDB 내부에 통합되어 tablespace 메타데이터도 서버의 핵심 메타데이터 관리 흐름 안에 들어간다.

운영자가 tablespace를 이해할 때 중요한 기준은 네 가지다.

어떤 객체가 해당 tablespace에 저장되는가.
파일 크기가 늘어난 뒤 다시 줄어드는가.
테이블 단위 이동·삭제·백업이 쉬운가.
장애 복구와 DDL 수행 중 어떤 제약을 만드는가.

3. system tablespace: InnoDB의 기본 저장 공간

System tablespace는 전통적으로 ibdata1 파일로 대표되는 InnoDB의 기본 tablespace다. MySQL 버전과 설정에 따라 역할은 달라졌지만, 여전히 InnoDB 운영에서 특별한 의미를 가진다.

MySQL 8.0 기준으로 system tablespace에는 다음과 같은 정보가 포함될 수 있다.

InnoDB 내부 시스템 정보
change buffer 관련 영역
일부 undo 관련 이력 또는 과거 설정에서 유입된 undo 정보
innodb_file_per_table=OFF 상태에서 생성된 테이블과 인덱스 데이터
과거 버전 또는 업그레이드 이력에 따라 남아 있는 내부 구조

MySQL 8.0의 데이터 딕셔너리는 이전 버전의 .frm 파일 중심 구조와 다르며 InnoDB에 통합되어 있다. 다만 운영자가 기억해야 할 핵심은 더 단순하다. ibdata1 같은 system tablespace 파일은 한번 커지면 일반적인 DROP TABLE이나 OPTIMIZE TABLE로 운영 중 축소되지 않는다. 즉, system tablespace에 사용자 테이블 데이터가 많이 들어가도록 운영하면 장기적으로 공간 회수가 어려워진다.

3.1 system tablespace가 커지는 대표 원인

System tablespace가 예상보다 커지는 원인은 보통 다음 중 하나다.

오래된 설정에서 innodb_file_per_table=OFF로 테이블을 생성했다.
대량 임시 작업, purge 지연, undo 관련 부하가 장기간 지속되었다.
MySQL 5.7 이하에서 운영하던 인스턴스를 업그레이드하면서 과거 구조의 흔적이 남았다.
대량 DDL·DML 작업 뒤 내부 공간은 재사용 가능하지만 파일 자체는 축소되지 않는다는 점을 고려하지 않았다.

MySQL 8.0 신규 운영에서는 기본적으로 innodb_file_per_table=ON이므로 일반 사용자 테이블은 개별 .ibd 파일로 생성된다. 그럼에도 업그레이드된 오래된 인스턴스에서는 system tablespace 비대화가 자주 발견된다.

3.2 system tablespace 운영 원칙

System tablespace는 줄이는 작업보다 “더 이상 불필요하게 키우지 않는 작업”이 중요하다.

신규 테이블은 특별한 이유가 없으면 file-per-table tablespace에 둔다.
innodb_file_per_table 값을 확인하고, 꺼져 있다면 신규 테이블 생성 정책을 재검토한다.
이미 커진 ibdata1을 줄이려면 일반적으로 logical dump, 인스턴스 재구성, restore가 필요하다.
디스크 용량 계획에서는 ibdata1이 줄어들지 않는다는 전제를 둔다.
system tablespace를 직접 파일 조작으로 줄이거나 삭제하지 않는다.

4. file-per-table tablespace: 현대 InnoDB의 기본 운영 단위

File-per-table tablespace는 각 InnoDB 테이블을 독립적인 .ibd 파일에 저장하는 방식이다. 예를 들어 app.orders 테이블은 데이터 디렉터리 아래 app/orders.ibd와 같은 형태로 저장된다. MySQL 8.0 이상에서 일반적인 운영 기본값은 innodb_file_per_table=ON이다.

이 방식에서는 테이블의 clustered index와 secondary index가 같은 테이블스페이스에 저장된다. InnoDB 테이블은 clustered index가 곧 테이블 데이터의 물리적 정렬 기준이다. Primary key가 있으면 primary key 순서로 clustered index가 구성되고, primary key가 없으면 InnoDB가 내부적으로 row identifier를 사용한다.

File-per-table의 장점은 운영 단위가 명확하다는 점이다.

DROP TABLE 후 해당 .ibd 파일이 제거되어 OS 수준 디스크 공간 반환이 쉽다.
TRUNCATE TABLE이 테이블 재생성에 가까운 방식으로 동작하면서 공간 반환에 유리하다.
테이블별 크기 확인과 용량 추적이 쉽다.
일부 시나리오에서 transportable tablespace 기능을 사용할 수 있다.
백업 도구나 스냅샷 분석에서 테이블 단위 추적이 쉽다.

그러나 단점도 있다.

테이블 수가 매우 많으면 파일 수가 많아지고 filesystem metadata 부하가 커질 수 있다.
작은 테이블이 매우 많을 때 tablespace metadata와 파일 단위 overhead가 누적된다.
테이블별 파일이 독립적이라고 해서 crash recovery가 테이블별로 완전히 독립되는 것은 아니다. redo log, undo, data dictionary와 함께 복구된다.
.ibd 파일만 복사한다고 항상 테이블을 복구할 수 있는 것은 아니다. dictionary metadata, LSN, encryption, discard/import 절차 등이 맞아야 한다.

4.1 file-per-table 설정 확인

다음 쿼리는 현재 서버의 innodb_file_per_table 설정과 주요 InnoDB 파일 관련 변수를 확인한다.

SHOW VARIABLES
WHERE Variable_name IN (
  'innodb_file_per_table',
  'innodb_data_file_path',
  'innodb_page_size',
  'datadir'
);

실행 결과(MySQL 8.0.46):

+-----------------------+------------------------+
| Variable_name         | Value                  |
+-----------------------+------------------------+
| datadir               | /var/lib/mysql/        |
| innodb_data_file_path | ibdata1:12M:autoextend |
| innodb_file_per_table | ON                     |
| innodb_page_size      | 16384                  |
+-----------------------+------------------------+

운영에서는 결과를 단순히 ON/OFF로만 보지 말고, “앞으로 생성될 테이블의 기본 배치 정책”으로 해석해야 한다. 이미 생성된 테이블의 tablespace가 자동으로 변경되는 것은 아니다.

4.2 테이블이 어느 tablespace에 있는지 확인

MySQL 8.0에서는 information_schema.INNODB_TABLES와 information_schema.INNODB_TABLESPACES를 이용해 InnoDB 내부 tablespace 정보를 확인할 수 있다. 다음 예제는 테스트 테이블을 만들고 해당 테이블의 tablespace 정보를 조회한다.

DROP TABLE IF EXISTS t_file_per_table;

CREATE TABLE t_file_per_table (
  id BIGINT PRIMARY KEY,
  note VARCHAR(100) NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

SELECT t.name AS innodb_table_name,
       s.name AS tablespace_name,
       s.space_type,
       s.row_format
FROM information_schema.INNODB_TABLES AS t
JOIN information_schema.INNODB_TABLESPACES AS s
  ON s.space = t.space
WHERE t.name = CONCAT(DATABASE(), '/t_file_per_table');

실행 결과(MySQL 8.0.46):

+----------------------------------+----------------------------------+------------+------------+
| innodb_table_name                | tablespace_name                  | space_type | row_format |
+----------------------------------+----------------------------------+------------+------------+
| mysql_tech_note/t_file_per_table | mysql_tech_note/t_file_per_table | Single     | Dynamic    |
+----------------------------------+----------------------------------+------------+------------+

DROP TABLE IF EXISTS t_file_per_table;

이 쿼리는 MySQL 8.0의 InnoDB dictionary view를 사용한다. 운영 환경에서는 view의 컬럼이 minor version에 따라 일부 차이가 날 수 있으므로, 자동화 스크립트에 넣기 전 대상 버전에서 SHOW COLUMNS로 확인하는 것이 좋다.

5. general tablespace: 여러 테이블을 하나의 tablespace에 담는 선택지

General tablespace는 사용자가 명시적으로 생성하는 공유 tablespace다. 여러 테이블을 하나의 tablespace에 배치할 수 있으며, 파일 경로와 이름도 지정할 수 있다. 문법은 대략 다음과 같다.

CREATE TABLESPACE ts_note_example
  ADD DATAFILE 'ts_note_example.ibd'
  ENGINE=InnoDB;

CREATE TABLE t_general_space (
  id BIGINT PRIMARY KEY,
  note VARCHAR(100) NOT NULL
) TABLESPACE ts_note_example ENGINE=InnoDB;

SELECT t.name AS innodb_table_name,
       s.name AS tablespace_name,
       s.space_type
FROM information_schema.INNODB_TABLES AS t
JOIN information_schema.INNODB_TABLESPACES AS s
  ON s.space = t.space
WHERE t.name = CONCAT(DATABASE(), '/t_general_space');

실행 결과(MySQL 8.0.46):

+---------------------------------+-----------------+------------+
| innodb_table_name               | tablespace_name | space_type |
+---------------------------------+-----------------+------------+
| mysql_tech_note/t_general_space | ts_note_example | General    |
+---------------------------------+-----------------+------------+

DROP TABLE IF EXISTS t_general_space;
DROP TABLESPACE ts_note_example;

General tablespace는 “여러 테이블을 하나의 큰 파일에 모아 관리하고 싶다”는 요구에 맞을 수 있다. 하지만 현대적인 일반 운영에서는 기본 선택지라기보다 특정 목적이 있을 때 검토하는 기능에 가깝다.

5.1 general tablespace의 장점

General tablespace가 유용할 수 있는 경우는 다음과 같다.

수많은 작은 테이블을 하나의 tablespace에 묶어 파일 수를 줄이고 싶다.
특정 스토리지 위치에 여러 테이블을 배치해야 한다.
테이블을 논리 그룹별로 묶어 공간 사용을 관찰하고 싶다.
file-per-table의 파일 수 증가가 운영상 부담이 되는 특수 환경이다.

5.2 general tablespace의 제한과 주의점

General tablespace는 공간 반환과 장애 격리 측면에서 file-per-table보다 직관적이지 않다.

tablespace 안의 일부 테이블을 DROP해도 tablespace 파일 자체가 즉시 줄어드는 것으로 기대하면 안 된다.
tablespace를 삭제하려면 그 안의 모든 테이블을 먼저 제거하거나 이동해야 한다.
특정 테이블만 OS 파일 단위로 분리해 다루기 어렵다.
transportable tablespace나 테이블 단위 복구 전략이 복잡해질 수 있다.
운영자가 tablespace 배치 정책을 계속 기억하고 문서화해야 한다.

따라서 general tablespace는 “기본값보다 좋아 보이기 때문에” 사용하는 기능이 아니다. 파일 수, 배치 위치, 작은 테이블 대량 운영 같은 명확한 목적이 있을 때만 선택해야 한다.

6. tablespace와 DDL: 공간 반환을 어떻게 해석할 것인가

InnoDB tablespace 운영에서 가장 흔한 질문은 “테이블을 지웠는데 왜 디스크가 줄지 않는가”다. 답은 테이블이 어느 tablespace에 있었는지에 따라 달라진다.

작업	file-per-table	system tablespace	general tablespace
`DROP TABLE`	`.ibd` 파일 삭제로 OS 공간 반환 가능	내부 공간 재사용 가능, 파일 축소는 일반적으로 불가	내부 공간 재사용 가능, 파일 축소는 일반적으로 불가
`TRUNCATE TABLE`	테이블 재생성으로 공간 반환에 유리	system 내부 공간 재사용 중심	tablespace 내부 공간 재사용 중심
`OPTIMIZE TABLE`	테이블 재구성으로 파일 축소 가능성이 있음	system 파일 자체 축소 기대는 부적절	공유 파일 축소 기대는 부적절
테이블 단위 이동	상대적으로 쉬움	어려움	tablespace 단위 제약 고려 필요

OPTIMIZE TABLE은 만능 공간 회수 명령이 아니다. InnoDB에서는 내부적으로 테이블 재구성 방식으로 동작할 수 있으며, 대량 redo/undo, 임시 공간, metadata lock, 복제 지연을 유발할 수 있다. 운영 시간대에 무심코 실행하면 디스크를 줄이려다 장애를 만들 수 있다.

대량 삭제 후 공간 반환이 필요하다면 다음 순서로 판단한다.

대상 테이블이 file-per-table인지 확인한다.
삭제 후 재사용만으로 충분한지, OS 공간 반환이 꼭 필요한지 구분한다.
OPTIMIZE TABLE, ALTER TABLE ... ENGINE=InnoDB, 테이블 재생성, 파티션 drop 등 가능한 방법의 잠금·로그·복제 영향을 계산한다.
복제 환경에서는 replica 지연과 binary log 크기를 함께 본다.
Aurora MySQL에서는 물리 파일 반환보다 cluster volume 과금·스냅샷·스토리지 재사용 특성을 별도로 확인한다.

7. Aurora MySQL에서의 차이

Aurora MySQL은 MySQL 호환 SQL 계층과 InnoDB 기반 실행 특성을 제공하지만, 스토리지 계층은 일반 Community MySQL과 다르다. Aurora는 분산 공유 스토리지 구조를 사용하므로 운영자가 Linux 파일시스템의 .ibd 파일 크기만 보고 전체 저장 구조를 판단하는 방식은 맞지 않는다.

Aurora에서도 innodb_file_per_table, tablespace metadata, InnoDB dictionary 개념은 SQL 호환성 측면에서 중요하다. 그러나 다음 차이를 반드시 고려해야 한다.

스토리지 확장과 복제는 Aurora cluster volume 계층에서 처리된다.
OS 파일을 직접 보고 공간 반환을 판단하는 방식은 제한적이다.
snapshot, clone, point-in-time recovery, fast failover가 일반 MySQL의 물리 파일 운용과 다르다.
Performance Insights, CloudWatch metrics, Aurora storage metrics를 함께 봐야 한다.
파일 단위 복구나 transportable tablespace 중심의 운영 절차는 Aurora에서 일반적인 복구 전략이 아니다.

따라서 Aurora MySQL에서는 tablespace 구조를 “SQL·DDL·metadata 동작을 이해하기 위한 모델”로 사용하되, 용량 회수와 백업 복구는 Aurora의 관리형 스토리지 기능을 기준으로 판단해야 한다.

8. 실무 진단 쿼리

다음 쿼리들은 MySQL 8.0 이상에서 tablespace 상태를 확인할 때 출발점으로 사용할 수 있다. 운영 환경에 적용하기 전에는 권한, view 컬럼, 데이터 규모를 확인하고 필요한 조건을 추가해야 한다.

8.1 InnoDB tablespace 목록 확인

SELECT name,
       space_type,
       row_format,
       page_size,
       state
FROM information_schema.INNODB_TABLESPACES
ORDER BY name
LIMIT 20;

실행 결과(MySQL 8.0.46):

+------------------+------------+----------------------+-----------+--------+
| name             | space_type | row_format           | page_size | state  |
+------------------+------------+----------------------+-----------+--------+
| innodb_temporary | System     | Compact or Redundant |     16384 | normal |
| innodb_undo_001  | Undo       | Undo                 |     16384 | active |
| innodb_undo_002  | Undo       | Undo                 |     16384 | active |
| mysql            | General    | Any                  |     16384 | normal |
| sys/sys_config   | Single     | Dynamic              |     16384 | normal |
+------------------+------------+----------------------+-----------+--------+

이 결과는 서버가 알고 있는 InnoDB tablespace의 논리 목록이다. 파일 경로를 직접 확인하는 것보다 데이터 딕셔너리 관점의 상태를 먼저 보는 것이 안전하다.

8.2 현재 schema의 테이블별 tablespace 유형 확인

DROP TABLE IF EXISTS t_ts_a;
DROP TABLE IF EXISTS t_ts_b;

CREATE TABLE t_ts_a (
  id INT PRIMARY KEY,
  value_col VARCHAR(30) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE t_ts_b (
  id INT PRIMARY KEY,
  value_col VARCHAR(30) NOT NULL
) ENGINE=InnoDB;

SELECT t.name AS innodb_table_name,
       s.name AS tablespace_name,
       s.space_type
FROM information_schema.INNODB_TABLES AS t
JOIN information_schema.INNODB_TABLESPACES AS s
  ON s.space = t.space
WHERE t.name IN (CONCAT(DATABASE(), '/t_ts_a'), CONCAT(DATABASE(), '/t_ts_b'))
ORDER BY t.name;

실행 결과(MySQL 8.0.46):

+------------------------+------------------------+------------+
| innodb_table_name      | tablespace_name        | space_type |
+------------------------+------------------------+------------+
| mysql_tech_note/t_ts_a | mysql_tech_note/t_ts_a | Single     |
| mysql_tech_note/t_ts_b | mysql_tech_note/t_ts_b | Single     |
+------------------------+------------------------+------------+

DROP TABLE IF EXISTS t_ts_a;
DROP TABLE IF EXISTS t_ts_b;

8.3 테이블 파일 경로 확인의 한계

운영자가 데이터 디렉터리에서 .ibd 파일을 보는 것은 유용할 수 있지만, 그것만으로 복구 가능성을 판단해서는 안 된다. 다음 쿼리는 현재 서버의 데이터 디렉터리와 file-per-table 설정을 보여준다.

SELECT @@datadir AS data_directory,
       @@innodb_file_per_table AS innodb_file_per_table,
       @@innodb_page_size AS innodb_page_size;

실행 결과(MySQL 8.0.46):

+-----------------+-----------------------+------------------+
| data_directory  | innodb_file_per_table | innodb_page_size |
+-----------------+-----------------------+------------------+
| /var/lib/mysql/ |                     1 |            16384 |
+-----------------+-----------------------+------------------+

이 결과는 서버 설정을 이해하기 위한 정보다. .ibd 파일을 직접 복사하거나 삭제하라는 의미가 아니다. InnoDB 파일은 데이터 딕셔너리, redo log, undo, checkpoint LSN과 함께 일관성을 가져야 한다.

9. 장애와 오해: tablespace에서 자주 발생하는 실수

9.1 `ibdata1`을 직접 줄이거나 삭제하려는 시도

ibdata1이 크다고 해서 MySQL을 끄고 파일을 줄이거나 삭제하면 InnoDB 인스턴스가 손상될 수 있다. System tablespace는 InnoDB 내부 메타데이터와 공간 관리 구조를 포함할 수 있으므로 파일 시스템 도구로 임의 조작해서는 안 된다. 축소가 필요하면 별도 인스턴스에 logical dump 후 restore하거나, 검증된 migration 절차로 재구성해야 한다.

9.2 `.ibd` 파일만 있으면 테이블을 복구할 수 있다는 오해

File-per-table이라고 해도 .ibd 파일은 독립적인 SQLite 파일처럼 동작하지 않는다. MySQL의 데이터 딕셔너리와 tablespace id, row format, encryption 상태, LSN 등이 맞아야 한다. DISCARD TABLESPACE와 IMPORT TABLESPACE 절차가 존재하지만, 이는 사전 조건과 제약을 갖는 복구·이동 기능이지 일반 백업 전략의 대체재가 아니다.

9.3 general tablespace를 공간 절약 기능으로만 보는 실수

General tablespace는 파일 수를 줄일 수 있지만, 공간 반환과 테이블 단위 운용을 복잡하게 만든다. 여러 테이블이 한 tablespace에 있으면 특정 테이블 삭제가 파일 축소로 바로 이어지지 않는다. 파일 수 감소와 운영 복잡도 증가를 비교해야 한다.

9.4 DDL의 로그 비용을 과소평가하는 실수

Tablespace 변경, 테이블 재구성, OPTIMIZE TABLE, 대량 ALTER TABLE은 redo log, undo, temporary space, binary log, replica apply 지연을 만들 수 있다. “공간을 줄이는 작업”은 종종 “대량 쓰기 작업”이다. 운영 시간대와 복제 구조를 고려하지 않으면 장애 원인이 된다.

9.5 MySQL 5.7 이하 정보 스키마 예제를 그대로 사용하는 문제

잠금 진단에서 자주 보이던 information_schema.INNODB_LOCKS, information_schema.INNODB_LOCK_WAITS는 MySQL 8.0에서 제거된 구식 객체다. 이 글의 tablespace 진단 예제에는 해당 객체를 사용하지 않는다. MySQL 8.0 이상의 잠금·대기 진단은 performance_schema.data_locks, performance_schema.data_lock_waits 같은 performance_schema 기반으로 접근해야 한다.

10. 운영 의사결정 기준

Tablespace 선택은 “성능이 더 빠른가” 하나로 결정할 문제가 아니다. 대부분의 일반 OLTP 서비스에서는 기본값인 file-per-table이 가장 운영 친화적이다. 예외를 선택하려면 목적과 비용을 명확히 적어야 한다.

10.1 기본 권장안

신규 MySQL 8.0 이상 인스턴스는 innodb_file_per_table=ON을 유지한다.
일반 사용자 테이블은 file-per-table tablespace를 기본으로 둔다.
system tablespace에는 사용자 테이블이 새로 들어가지 않도록 한다.
general tablespace는 파일 수 감소, 특정 위치 배치 등 명확한 사유가 있을 때만 사용한다.
tablespace 변경은 DDL 비용, 복제 영향, 백업 전략을 함께 검토한 뒤 실행한다.

10.2 점검 체크리스트

innodb_file_per_table `innodb_file_per_table`이 현재 의도한 값인지 확인했다.
오래된 테이블 중 system tablespace에 남아 있는 객체가 있는지 확인했다.
ibdata1 `ibdata1` 증가 원인을 단순 파일 크기가 아니라 테이블 배치와 과거 운영 이력으로 해석했다.
대량 삭제 후 OS 공간 반환이 필요한 테이블과 내부 재사용만으로 충분한 테이블을 구분했다.
OPTIMIZE TABLE `OPTIMIZE TABLE` 또는 재구성 DDL의 redo/undo/temp/binary log 비용을 계산했다.
replica 또는 Aurora reader에 미칠 지연 영향을 확인했다.
general tablespace 사용 시 포함 테이블 목록과 삭제·이동 절차를 문서화했다.
.ibd `.ibd` 파일 직접 복사·삭제를 백업이나 복구 절차로 사용하지 않는다는 원칙을 공유했다.
Aurora MySQL에서는 파일 경로보다 cluster volume, snapshot, CloudWatch 지표를 기준으로 용량과 복구를 판단했다.

11. 결론

InnoDB tablespace는 SQL 표면 아래에서 테이블과 인덱스가 실제로 배치되는 저장 단위다. System tablespace는 InnoDB의 기반 공간이며 한번 커진 파일을 운영 중 줄이기 어렵다. File-per-table tablespace는 현대 MySQL에서 일반 테이블의 기본 운영 단위로, 테이블별 공간 반환과 관리에 유리하다. General tablespace는 여러 테이블을 묶는 선택지이지만, 공간 반환과 복구 단위가 복잡해지므로 명확한 목적이 있을 때만 사용해야 한다.

운영자는 tablespace를 단순 파일 이름이 아니라 DDL 비용, 백업·복구 전략, 디스크 용량 계획, Aurora 스토리지 차이까지 연결되는 구조로 이해해야 한다. 다음 단계에서는 InnoDB page와 extent, segment가 tablespace 안에서 어떻게 배치되고, 이 구조가 buffer pool과 redo log 동작에 어떤 영향을 주는지 더 깊게 살펴볼 수 있다.

1. 왜 테이블스페이스 구조를 이해해야 하는가

2. InnoDB tablespace의 기본 개념

3. system tablespace: InnoDB의 기본 저장 공간

3.1 system tablespace가 커지는 대표 원인

3.2 system tablespace 운영 원칙

4. file-per-table tablespace: 현대 InnoDB의 기본 운영 단위

4.1 file-per-table 설정 확인

4.2 테이블이 어느 tablespace에 있는지 확인

5. general tablespace: 여러 테이블을 하나의 tablespace에 담는 선택지

5.1 general tablespace의 장점

5.2 general tablespace의 제한과 주의점

6. tablespace와 DDL: 공간 반환을 어떻게 해석할 것인가

7. Aurora MySQL에서의 차이

8. 실무 진단 쿼리

8.1 InnoDB tablespace 목록 확인

8.2 현재 schema의 테이블별 tablespace 유형 확인

8.3 테이블 파일 경로 확인의 한계

9. 장애와 오해: tablespace에서 자주 발생하는 실수

9.1 ibdata1을 직접 줄이거나 삭제하려는 시도

9.2 .ibd 파일만 있으면 테이블을 복구할 수 있다는 오해

9.3 general tablespace를 공간 절약 기능으로만 보는 실수

9.4 DDL의 로그 비용을 과소평가하는 실수

9.5 MySQL 5.7 이하 정보 스키마 예제를 그대로 사용하는 문제

10. 운영 의사결정 기준

10.1 기본 권장안

10.2 점검 체크리스트

11. 결론

9.1 `ibdata1`을 직접 줄이거나 삭제하려는 시도

9.2 `.ibd` 파일만 있으면 테이블을 복구할 수 있다는 오해