The data files that you define in the configuration file form the tablespace of InnoDB. The files are simply concatenated to form the tablespace. There is no striping in use. Currently, you cannot define where within the tablespace your tables are allocated. However, in a newly created tablespace, InnoDB allocates space starting from the first data file.

The tablespace consists of database pages with a default size of 16KB. The pages are grouped into extents of 64 consecutive pages. The “files” inside a tablespace are called segments in InnoDB. The term “rollback segment” is somewhat confusing because it actually contains many
tablespace segments.

Two segments are allocated for each index in InnoDB. One is for non-leaf nodes of the B-tree, the other is for the leaf nodes. The idea here is to achieve better sequentiality for the leaf nodes, which contain the data.

When a segment grows inside the tablespace, InnoDB allocates the first 32 pages to it individually. After that InnoDB starts to allocate whole extents to the segment. InnoDB can add to a large segment up to 4 extents at a time to ensure good sequentiality of data.

Some pages in the tablespace contain bitmaps of other pages, and therefore a few extents in an InnoDB tablespace cannot be allocated to segments as a whole, but only as individual pages.

When you ask for available free space in the tablespace by issuing a SHOW TABLE STATUS statement, InnoDB reports the extents that are definitely free in the tablespace. InnoDB always reserves some extents for cleanup and other internal purposes; these reserved extents are not included in the free space.

When you delete data from a table, InnoDB contracts the corresponding B-tree indexes. Whether the freed space becomes available for other users depends on whether the pattern of deletes frees individual pages or extents to the tablespace. Dropping a table or deleting all rows from it
is guaranteed to release the space to other users, but remember that deleted rows are physically removed only in an (automatic) purge operation after they are no longer needed for transaction rollbacks or consistent reads. (See Section 12.5.12, “Implementation of Multi-Versioning”.)

설정file을 정의하는 datafile로부터, InnoDB의 tablespace가 구성 됨. 이 file들은, 단순하게 연결된 tablespace가 됨. striping은 사용하지 않음. 현시점에서, tablespace의 어떤 위치에 table이 할
당되어있는지는 정의 불가능함. 그러나, 새롭게 작성되는 tablespace내에서는 InnoDB가 최초의datafile부터 영역을 할당함.

Tablespace는, default size가 16KB의 database page로 구성. 이 page들은, 64개의 연속한 page로부터 extents 되어 group화함. InnoDB는, tablespace내부의 “files”을 segment라고 부름. 이것은 실제로 많은 tablespace segment를 포함하고 있기 때문에, “rollback segment”라는 이름은, 다소 오해를 일으킬 수 있음.

InnoDB는, 각 index에 2개의 segment를 할당함. 1개는 B Tree의 non-leaf nodes용, 다른 1개는 leaf nodes용. 이것에는, data를 포함하고 있는 leaf nodes에서 연속성을 높이는 의미.

Tablespace내의 segment가 커지면, InnoDB는 그 segment에 최초의 32page를 별도로 할당. InnoDB는 그 후, extents 전체를 segment에 할당하기 시작함. InnoDB는 data의 연속성을 확보하기 위해, 큰 segment에 한번에 최대 4개의 extents를 추가 가능함.

Tablespace에는, 다른 page의 hitmap을 포함한 page가 있기때문에, InnoDB tablespace내의 몇몇의 extents는, 전체가 아닌 별도의 page만 segment에 할당 하는 것이 가능함.

SHOW TABLE STAUS statement를 발행하고 tablespace내의 빈 영역을 조회하면, InnoDB로부터 tablespace내의 완전하게 비어있는 extents가 보고 됨. InnoDB는, 항상 몇몇의 extents를 clean up, 그 외의 내부적인 용도를 위해 확보하기도 하고, 이 extents은 빈 영역에 포함하지 않음.

Table에서 data를 삭제하면, InnoDB에 따라 대응한 B Tree index가 축소됨. 이 것에 따라, 다른 user가 개방된 영역을 사용가능하도록 할지 어떨지는, 삭제 pattern이 tablespace의 가각의 page나 extents를 개방할지 어떨지에 따라 달라짐. table를 파괴하거나, 또는 table로부터 모든 행을 삭제하면, 다른 user에 확실하게 영역이 개방되지만, 삭제된 행은, transaction rollback 또는 일괄적
인 read로 그 record가 필요없어 진 후의 page 조작에서 처음으로 물리적으로 삭제되는 것에 주의해 주세요. (자세한 것은 “Multi version 실행”을 참조 해 주세요.)