Not possible easily because you could already have tables inside a old innodb table space.

It seems that innodb_file_per_table =

has been implemented so that you can use table with different values but at the moment only using shutdown. innodb_file_format affects how actual storage of file is interpreted and changing that is not safe. Why you say that creating tables from concurrent threads is unsafe? It should not be, similarly alter table with copy to different tables on different threads should be safe. If not, there is a bug.

I'm not sure, probably my explaination was not clear. I'll show an example, so you can judge if what I'm asking makes sense:

MariaDB [test_innodb]> SET @@global.innodb_file_per_table = OFF;
Query OK, 0 rows affected (0.01 sec)

MariaDB [test_innodb]> CREATE TABLE uno (a INT PRIMARY KEY) ENGINE = InnoDB;
Query OK, 0 rows affected (0.28 sec)

MariaDB [test_innodb]> SET @@global.innodb_file_per_table = ON;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test_innodb]> ALTER TABLE uno FORCE;
Query OK, 0 rows affected (0.89 sec)               
Records: 0  Duplicates: 0  Warnings: 0

After CREATE, uno exists in the sys tablespace; after ALTER, it has its own ibd file.

What I mean by "unsafe" is that thread1 might change innodb_file_per_table immediatly before thread2 ALTERs a table. The only way I know to avoid this is that all threads do things like this every time they ALTER a table:

SELECT GET_LOCK(...);
SET innodb_file_per_table = 1;
SET innodb_file_format = 'Barracuda';
ALTER ...
DO RELEASE_LOCK(...);

...unless only 1 thread can CREATE/ALTER.

Does my request make sense?

Indeed, one can change innodb_file_per_table at runtime. Which allows to have some tables in their own tablespaces and some other tables — in one big tablespace.

I'd still expect that doing it per thread would require big changes inside InnoDB, but I let Jan Lindström answer that.

Desided not to support.