Creating and listing databases
MySQL lists databases with the SHOW DATABASES statement, which returns every schema the connected account can see, and creates new ones with CREATE DATABASE, which you can pair with a character set and a collation in the same line.
On a stock install you will usually see 3 to 5 rows in that first list, starting with information_schema, the built-in catalog that mirrors the server's own metadata. One schema holds the tables, indexes, views and stored routines that belong to a single application, so the command below is the fastest way to confirm what MySQL on this box is actually serving.
Run SHOW DATABASES from the mysql client and it prints one schema name per line, without the USE context of any table. The output is ordered alphabetically, so a dev box with wordpress, shop and staging shows up in that order regardless of when each was created. If the list looks shorter than expected, the cause is usually permissions rather than a missing schema: the account you logged in with may only be granted access to a subset of them, and MySQL hides the rest entirely rather than listing them as locked. The same statement also works inside any SQL editor, which keeps it handy for the day to day flow in MySQL in practice. A graphical path to the same list appears in a MySQL Workbench walkthrough, and the bigger question of which engine you are standardising on belongs to Choosing between MySQL and PostgreSQL. For the command line side of listing, creating and inspecting schemas, the muscle memory you build with basic Linux Commands carries straight over, because the mysql client reads from stdin and writes to the terminal in exactly the way ls or grep do.
List every database on the server
To list every database, connect with the mysql client and run the statement. The minimal session looks like this:
mysql -u root -pto open a session with the administrative account.SHOW DATABASES;to print the visible schema names, one per line.SELECT SCHEMA_NAME FROM information_schema.SCHEMATA;to query the catalog directly instead.
The information_schema route is the one worth keeping, because it turns the list into queryable data. You can filter it with a WHERE clause, join it against information_schema.TABLES to count tables per schema, or pull the collation with SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA;. That last query is the 30 second way to audit whether a schema drifted onto latin1 after an old migration script ran against it. The statement form and the catalog form return the same names, but the catalog form is what you script, since it accepts filters and returns columns rather than a fixed grid of rows.
What a database, schema and table actually mean
A database and a schema are the same object in MySQL, and a table is a named set of rows that lives inside one of them. The confusion is historical: in the SQL standard the two terms are distinct, but MySQL uses "database" for the container and treats "schema" as a synonym for it, so CREATE DATABASE shop and any reference to the shop schema point at the identical directory under the data folder. A table is the next level down, a single relation with columns, and one schema can hold any number of tables. The practical difference shows up in the command line, where you type CREATE DATABASE and CREATE TABLE but the catalog calls both the schema and the table a row in its own metadata tables.
Create a database with a character set and collation
To create a database, issue CREATE DATABASE with the name, and pin the character set and collation in the same statement. The default collation of a utf8mb4 database is utf8mb4_0900_ai_ci on MySQL 8.0, but older 5.7 servers defaulted to utf8_general_ci, which is why a schema created years ago may still carry a collation that sorts accented characters differently than a schema created this year. The full form is:
CREATE DATABASE shop CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
The character set decides which bytes a column can store, and the collation decides how two values compare for equality and order. utf8mb4 covers the full Unicode range, including emoji, in 1 to 4 bytes per character, which is the safe default for any text column. The collation suffix is where most of the behaviour lives: ci means case insensitive, bin means binary and case sensitive, and ai means accent insensitive. If two applications share one server, you want both to pin the same collation at creation time, because a join between a table in one schema and a table in another fails with an "Illegal mix of collations" error the moment the two collations disagree. That error is one of the most common surprises on a mixed vintage server, and it is cheapest to avoid at CREATE DATABASE rather than to fix column by column later.
Make the new database survive a restart
To make the new database durable, confirm that it is on disk and that a user can see it, because creation in the session and visibility to the application are two separate facts. After CREATE DATABASE returns, the schema is already written to the data directory, so a restart of the server does not drop it; what you need to verify is that the account your application uses has been granted access to it. Run SHOW GRANTS FOR 'appuser'@'localhost'; and look for a line that names the new schema, or add one with GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'appuser'@'localhost';. The wildcard in shop.* covers every table in the schema, which is the right scope for an application account, and it keeps the grant from leaking into the other schemas on the box. This step is the one that is missing the most often, and it is the reason a freshly created database appears empty to the app even though the tables exist.
Inspect, rename and drop a schema
To inspect a schema you are not sure about, query the catalog for its tables and sizes before you touch it. The statement SELECT TABLE_NAME, TABLE_ROWS, DATA_LENGTH FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'shop'; gives you a 1 line summary per table, with DATA_LENGTH in bytes so you can see which table actually holds the data. To rename a schema you change its collation in place with ALTER DATABASE shop CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;, but note that the schema name itself is not something you rename with that statement; renaming the directory is a manual move of the schema folder under the data directory and an update of any grants that reference it, so it is the one operation on a schema that is best avoided and planned ahead of time. To drop a schema, DROP DATABASE shop; removes the directory and every table inside it in one step, and the statement gives you no undo, so confirm the name against the SHOW DATABASES list before you run it. The drop is the reason the listing habit from the first section matters: the list is the 2 second check that tells you which of the 4 or 5 schemas on the box is the one you actually intend to remove.