dynamic or static database tables
Relational databases in general, but specifically MySQL are thought to have a static structure. Let me elaborate a bit on what static entails (as it doesn't necessarily mean immutable):


  Each version of the application should work with a predefined set of
  tables and internal structure


Only when requirements change (be it functional or things like performance improvements) you will perform an application "migration" to adapt the logic and data to the new ones, and add, delete or ALTER existing tables. If your table structure changes frequently (compared to the number of read and write operations), that is normally a sign of a bad design.

In particular, new users or state of an application (sessions), should not create new sets of tables, but add rows to existing ones.

As exceptions, Schema-based Multi-tenancy is a pattern that would fit the "creation of a new database" for each "application user group", but normally the scope of that is new organizations sharing the same software, or separate communities that require separate configuration; and normally with things like security or cost in mind. For sessions, table-based multi-tenancy is probably the most common pattern.

Dynamicaly creating and deleting tables usually has a high cost compared to inserting and deleting rows, specially on MySQL (creation of new tablespaces, invalidating high regions of memory, extra metadata locking, etc.)