I've been experimenting with MariaDB (Win32 / 5.5.34-MariaDB-31.1), trying to use it as a DB server for a real-time archive application. I use `innodb_file_per_table=1`, so every table is a separate `.ibd` file. That's convenient for maintenance such as `OPTIMIZE TABLE` when old data will be deleted.

I have a small test application with some 2,600 tables (one table is used per an archived object). On the disk these tables consume some 12 GB, useful data (`data_length` + `index_length`) is about 4 GB (so far I've been only inserting/updating rows, no deletes). When adding `data_length` + `index_length` + `data_free`, I see 9 GB.

The major problem seems to be the way individual `.ibd` files grow. I've performed 2 tests (on both `COMPACT` and `COMPRESSED` tables). First they grow by few kB, but then their size jumps. E.g.: 163 kB, 180 kB, 229 kB ... 589 kB, 606 kB and then jump to 2 MB, then to 9 MB.

This observation agrees with [the documentation](http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_autoextend_increment) which says:

> 
> This variable does not affect the per-table tablespace files that are
>  created if you use `innodb_file_per_table=1`. Those files are
>  auto-extending regardless of the value of `innodb_autoextend_increment`.
>  The initial extensions are by small amounts, after which extensions
>  occur in increments of 4 MB.
> 
> 
> 

So it seems every table (grown above some limit) has 0-4 MB unused but allocated space (let's say 2 MB on average). I wasn't able to find anything in documentation which would suggest this extent size can be configured. And that's my question:

Can this auto-extension size be changed on MySQL/MariaDB/other alternative to MySQL? The current 2 MB per table is an unacceptably high overhead (production systems may have 100,000 tables or more, that is 200 GB wasted space).

When we use Oracle, it doesn't have a 'one\_file\_per\_table' option, but to avoid fragmentation of datafiles (caused by deleting old data and then tidying up by `alter table shrink space`) the tablespace is created using `space EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128 K` which tells Oracle to use a fixed-size extent instead of default growing extent size.
(the default growing-extent caused situations when a fixed-size tablespace had over 10 GB of free space, but a table was not able to expand because there was not a sufficiently large contiguous block available. All 10 GB was reclaimed after deleting old data which was in small extents).