왜 innodb_file_per_table을 사용합니까?
파일 수준에서 수행 할 수 있으므로 개인을 관리하기가 더 쉽습니다. 즉, 서버가 다운 된 경우에도 테이블 파일을 복사하여 데이터를 복사 할 수 있지만 공유 테이블 스페이스를 사용하면 불필요하게 대규모 일 수있는 모든 것을 복사 하거나 서버가 데이터를 추출하도록 실행할 수있는 방법을 찾는다는 의미입니다 ( 실제로 16 진 편집기로 데이터를 수동으로 추출하고 싶지는 않습니다.
누군가가 단순히 .ibd한 서버에서 다른 서버로 파일을 복사하여 붙여 넣을 수는 없다고 경고 했습니다 . 이것은 사실 일 수 있지만 동일한 서버의 백업에는 적용해서는 안됩니다 ( 전반적으로 사본을 만드는 의미에서 백업 이라는 용어를 사용하고 있습니다. 즉, 전체를 크게 변경하지는 않습니다). 또한 ibdata1시작시 자동으로 다시 작성됩니다 ( 대부분의 "테이블 당 파일로 변환"안내서 의 삭제ibdata1 단계에 표시됨). 따라서 파일 (및 해당 파일 등) 외에 복사 할 필요 가 없습니다 .ibdata1.ibd.frm
잃어버린 테이블을 복구하려는 경우 해당 복사하기에 충분해야 .ibd하고 .frm파일을뿐만 아니라 information_schema(어느 정도 보다 작은 ibdata1). 이렇게하면 더미 서버에 넣고 전체를 복사하지 않고도 테이블을 추출 할 수 있습니다.
그러나 더 나은 성능에 대한 주장은 의문의 여지가 있습니다. … innodb_file_per_table을 사용하면 더 많은 디스크 I / O 작업이 필요합니다. 복잡한 JOIN 및 FOREIGN KEY 제약 조건에서 중요합니다.
당연히 성능은 사용중인 특정 데이터베이스에 전적으로 의존합니다. 한 사람은 다른 사람과는 (대부분의) 다른 결과를 가질 것입니다.
테이블 당 파일로 더 많은 디스크 I / O 작업이 있지만 약간만 더있을 것입니다. 시스템이 어떻게 작동하는지 생각하십시오.
모 놀리 식 데이터베이스의 경우 :
- 서버가 시작되었습니다
ibdata1 열렸다- 헤더 및 메타 데이터를 읽습니다.
- 구조와 메타 데이터는 메모리에 캐시됩니다
- 쿼리가 발생합니다
- 서버가 디스크에 액세스하여 이미 열린 데이터를 읽습니다.
ibdata1
- 서버가 메모리에 데이터를 캐시 할 수 있습니다
테이블 당 데이터베이스의 경우 :
- 서버가 시작되었습니다
ibdata1 열렸다- 헤더 및 메타 데이터를 읽습니다.
- 각 개별
.ibd파일이 열립니다
- 각
.ibd파일 에서 헤더 및 메타 데이터를 읽습니다.
- 구조와 메타 데이터는 메모리에 캐시됩니다
- 쿼리가 발생합니다
- 서버가 디스크에 액세스하여 이미 열린
.ibd파일 에서 데이터를 읽습니다.
- 서버가 메모리에 데이터를 캐시 할 수 있습니다
서버가 실행 중일 때 서버에 열린 핸들이 있기 때문에 데이터 파일을 이동할 수 없습니다. 시작될 때 열어서 열어두기 때문입니다. 개별 쿼리마다 열거 나 닫지 않습니다.
따라서 서버가 시작될 때 처음에는 더 많은 I / O 작업 만 있습니다. 실행 중이 아닙니다. 또한 각 개별 .ibd파일에는 고유 한 별도의 오버 헤드 (파일 서명, 구조 등)가 있지만 메모리에 캐시되어 각 쿼리에 대해 다시 읽지 않습니다. 또한 공유 테이블 스페이스를 사용하더라도 동일한 구조를 읽으므로 더 많은 메모리가 필요하지 않습니다.
innodb_file_per_table이 mysql의 성능 향상에 영향을 줍니까?
어떤 경우에는 사실, 성능은 사실 수 있을 악화 .
공유 테이블 스페이스를 사용하는 경우 서버에서 여러 테이블의 데이터 견본을 한 번에 읽을 수 있도록 읽기 및 쓰기 작업을 결합 할 수 있습니다 ibdata.
그러나 데이터가 여러 파일로 분산 된 경우 각 파일에 대해 개별 I / O 작업을 개별적으로 수행해야합니다.
물론 이것은 다시 해당 데이터베이스에 전적으로 의존합니다. 실제 성능 영향은 크기, 쿼리 빈도 및 공유 테이블 스페이스의 내부 조각화에 따라 다릅니다. 어떤 사람들은 큰 차이를 느끼는 반면 다른 사람들은 전혀 영향을받지 않을 수도 있습니다.
테이블 스페이스는 단일 ibdata에서 공유됩니다. 어떻게 별도의 테이블 전용 테이블 스페이스가 디스크 공간을 절약 할 수 있습니까?
그렇지 않습니다. 무엇이든 디스크 사용량 이 증가 합니다.
테스트 할 60GB 데이터베이스는 없지만 WordPress 설치 및 개인용 사용 및 개발 테스트를위한 몇 개의 작은 테이블이 포함 된 "팔레트"개인 데이터베이스는 공유 테이블 스페이스를 사용하는 동안 ~ 30MB로 측정되었습니다. 테이블 당 파일로 변환 한 후 ~ 85MB로 팽창했습니다. 모든 것을 삭제하고 다시 가져와도 여전히 60MB가 넘습니다.
이 증가는 두 가지 요인에 기인합니다.
절대 최소 크기에 대한 ibdata1것입니다 - 몇 가지 이유 - 10메가바이트, 당신은 아무것도하지만 경우에도 information_schema그 안에 저장됩니다.
공유 테이블 스페이스를 사용하면 ibdata1파일 서명, 메타 데이터 등과 같은 오버 헤드 만 발생 하지만 테이블 당 각 개별 .ibd파일에는이 모든 것이 있습니다. 이것은 전체가 (가설이 <10MB 인 경우에도 ibdata1) 적어도 다음과 같이 다소 커질 것임을 의미합니다.
GetTotalSizeofOverhead() * GetNumTables()
분명히 데이터베이스 크기를 제한하거나 플래시 드라이브에 저장하는 호스트를 사용하지 않는 한 크게 증가하지는 않지만 그럼에도 불구하고 테이블 마다 파일 로 전환하여 증가 합니다. -테이블 당 ibdata110MB로 축소 할 수 있으며 전체 총계는 항상 그 이상입니다.