테이블을 절약하거나 제거 할 때 운영 체제의 디스크 공간을 다시 사용할 수 있습니다. file-per-table 모드가 해제로 전환 될 때 생성 된 테이블의 경우 테이블을 절약하거나 제거 할 때 내부적으로 ibdata 파일 에 여유 공간이 만들어집니다 만, 그 공간은 새로운 InnoDB 데이터에만 사용할 수 있습니다.

TRUNCATE TABLE 작업은 개별 .ibd 파일에서 실행하는 것보다 빠릅니다.

I / O 최적화, 용량 관리, 또는 밥 업을 위해 특정 테이블을 별도의 저장 장치에 저장할 수 있습니다. 이전 릴리스에서는 섹션 8.11.3.1 "심볼릭 링크 사용" 에 명시된 바와 같이 다른 드라이브에 데이터베이스 디렉토리 전체를 이동하고 MySQL 데이터 디렉토리에 심볼릭 링크를 생성해야했습니다. MySQL 5.6.6 이후에서는 섹션 14.5.4 "테이블 공간의 위치 지정" 에서 언급 된 바와 같이, 구문 CREATE TABLE ... DATA DIRECTORY = absolute_path_to_directory 를 사용하여 각 테이블의 위치를 확인할 수 있습니다.

OPTIMIZE TABLE 을 실행하여 테이블 공간을 압축하거나 다시 만들 수 있습니다. OPTIMIZE TABLE 을 실행하면 InnoDB 는 실제 데이터를 저장하는 데 필요한 공간만을 사용하여 임시 이름을 가지는 새로운 .ibd 파일을 만듭니다. 최적화가 완료되면 InnoDB 는 오래된 .ibd 파일을 삭제하고 새 .ibd 파일로 대체합니다. 이전 .ibd 파일은 매우 커졌지 만 실제 데이터는 그 크기의 일부를 차지하는 만의 경우 OPTIMIZE TABLE 을 실행하면 사용되지 않는 공간을 다시 사용할 수 있습니다.

전체 데이터베이스가 아닌 개별 InnoDB 테이블을 이동할 수 있습니다.

있는 MySQL 인스턴스에서 다른 인스턴스로 개별 InnoDB 테이블을 복사 할 수 있습니다 ( 이동 가능한 테이블 스페이스 기능으로 알려져 있습니다).

innodb_file_per_table 이 활성화 될 때 생성 된 테이블은 Barracuda 파일 형식을 사용할 수 있습니다. Barracuda 파일 형식은 압축 및 동적 라인 포맷 등의 기능을 지원합니다. innodb_file_per_table 이 꺼진 상태에서 작성된 테이블은 이러한 기능을 사용할 수 없습니다. 이러한 기능을 기존 테이블에 이용하려면 file-per-table 설정을 선택하여 기존의 테이블에서 ALTER TABLE t ENGINE=INNODB 를 실행합니다. 테이블을 변환하기 전에 섹션 14.6.4 "MyISAM에서 InnoDB의 테이블 변환" 을 참조하십시오.

동적 행 형식 을 사용하여 큰 BLOB 또는 텍스트 열을 가진 테이블에서 스토리지 효율성을 향상시킬 수 있습니다.

innodb_file_per_table 을 사용하면 복구가 성공할 가능성이 높아질 수 있습니다. 또한 손상이 발생한 경우 서버를 다시 시작할 수없는 경우 또는 백업 및 바이너리 로그를 사용할 수없는 경우 시간을 절약 할 수 있습니다.

MySQL Enterprise Backup 제품을 사용하여 다른 InnoDB 테이블의 사용을 중단하지 않고 하나의 테이블을 신속하게 백업하고 복원 할 수 있습니다. 자세한 내용은 Partial Backup and Restore Options 를 참조하십시오.

File-per-table 모드를 사용하면 백업에서 테이블을 제외 할 수 있습니다. 이것은 너무 자주 백업 할 필요가없는 테이블 또는 다른 일정으로 백업 할 테이블에 유효합니다.

file-per-table 모드는 테이블을 복사하거나 백업 할 때보고하는 각 테이블의 상태에 유용합니다.

file-per-table 모드를 사용하면 MySQL에 접근하지 않고 파일 시스템 레벨에서 테이블 크기를 모니터 할 수 있습니다.

일반적인 Linux 파일 시스템에서는 innodb_flush_method 를 O_DIRECT 에 설정되어있는 경우 하나의 파일로 병렬 쓰기는 허용되지 않습니다. 그 결과, innodb_flush_method 와 함께 innodb_file_per_table 을 사용하면 성능을 향상시킬 수 있습니다.

innodb_file_per_table 가 무효 인 경우, 테이블 데이터 사전 및 Undo 로그에 하나의 공유 테이블 공간 (시스템 테이블 공간)이 있습니다. 이 하나의 테이블 공간의 크기 제한은 64TB입니다. innodb_file_per_table 이 활성화되면 각 테이블에는 자신의 테이블 공간이 있고 각 테이블 공간의 크기 제한은 64TB입니다. 자세한 내용은 섹션 D.10.3 "테이블 크기 제한" 을 참조하십시오.

innodb_file_per_table 의 경우 각 테이블에는 사용하지 않는 테이블 공간이있을 수 있으며 그 테이블 공간을 이용할 수있는 것은 같은 테이블의 행뿐입니다. 이것은 테이블 공간이 제대로 관리되지 않으면 불필요한 테이블 공간이 줄어드는 것이 아니라 늘어나는 결과가 될 가능성이 있습니다.

fsync 작업은 하나의 파일이 아니라 각 오픈 테이블에서 실행해야합니다. 파일에 대해 별도의 fsync 조작으로 인해 여러 테이블에 쓰기 작업을 하나의 I / O 작업에 결합 할 수 없습니다. 따라서 InnoDB 는 fsync 조작의 수를 늘려 수행해야있을 수 있습니다.

mysqld는 테이블 당 하나의 오픈 파일의 처리를 유지할 필요가 있기 때문에 대량의 테이블이있는 경우 성능에 영향을 줄 수 있습니다.

더 많은 파일 디스크립터가 사용됩니다.

innodb_file_per_table 는 MySQL 5.6.6 이후에서는 기본적으로 켜져 있습니다. MySQL 5.5 또는 5.1과의 하위 호환성에 문제가있는 경우, 무효화 검토를 권장합니다. innodb_file_per_table 을 해제하면 ALTER TABLE 테이블 ( ALGORITHM=COPY )을 다시 작성하는 경우, ALTER TABLE 에서 InnoDB 테이블이 시스템 테이블 스페이스에서 개별 .ibd 파일로 이동하는 것이 억제된다.

예를 들어, InnoDB 테이블의 클러스터 인덱스를 다시 작성하는 경우, 테이블은 innodb_file_per_table 의 현재 설정을 사용하여 다시 작성됩니다. 이 동작은 InnoDB 의 보조 인덱스를 추가하거나 제거 할 때는 적용되지 않습니다. 보조 인덱스가 테이블을 다시 작성하지 않고 작성된 경우 현재 innodb_file_per_table 설정에 관계없이 그 인덱스는 테이블 데이터와 동일한 파일에 저장됩니다.

테이블이 증가 할 때 DROP TABLE 및 테이블 스캔의 성능이 떨어질 수있는 단편화가 늘어날 수 있습니다. 그러나 단편화 관리되는 경우 파일 자신의 테이블 공간에 파일이 있으면 성능이 향상 될 수 있습니다.

버퍼 풀은 테이블 당 테이블 공간을 제거 할 때 검사되기 때문에 크기가 수십 기가 바이트의 버퍼 풀에 몇 초 정도 걸릴 수 있습니다. 검사는 광범위하게 내부 잠금을 실행되므로 다른 작업을하지 않는 경우가 있습니다. 공유 테이블 스페이스의 테이블에 영향을주지 않습니다.

자동 증가 공유 테이블 스페이스가 꽉 찬 경우 그 크기를 확장 할 경우 증분 크기 (MB)를 정의하는 innodb_autoextend_increment 변수는 file-per-table 테이블 공간 파일에 적용되지 않습니다. innodb_autoextend_increment 의 값에 관계없이 file-per-table 테이블 공간 파일은 자동 확장입니다. 확장은 소량으로 시작하여 확장 증분가 4MB에서 발생합니다.