Introduction

Checking whether a MySQL database exists is simple, but the best method depends on whether you are working interactively, from SQL, or from application code. The most important operational detail is that existence checks depend on user permissions, so "not found" can sometimes mean "not visible to this account."

Quick Manual Check with SHOW DATABASES LIKE

For an interactive shell or an operational one-liner, the fastest check is:

SHOW DATABASES LIKE 'app_db';

If the command returns a row, the database exists and is visible to the current user. If it returns nothing, either the database does not exist or the current account does not have permission to see it.

That visibility rule is easy to forget, especially when diagnosing environment problems.

Metadata Query with INFORMATION_SCHEMA

If you want a query that fits neatly inside scripts or automation, inspect INFORMATION_SCHEMA.SCHEMATA.

SELECT SCHEMA_NAME
FROM INFORMATION_SCHEMA.SCHEMATA
WHERE SCHEMA_NAME = 'app_db';

You can also turn it into a count.

SELECT COUNT(*) AS db_exists
FROM INFORMATION_SCHEMA.SCHEMATA
WHERE SCHEMA_NAME = 'app_db';

A result of 1 means the schema is visible and exists. A result of 0 means it is absent or hidden from the current user.

Application Code Should Connect to the Server First

A very common mistake is trying to connect directly to the target database before checking whether it exists. If the schema does not exist, the connection itself fails and you never reach the existence logic.

Instead, connect to the MySQL server without selecting the target database first.

1import mysql.connector
2
3
4def database_exists(db_name: str) -> bool:
5    conn = mysql.connector.connect(
6        host="localhost",
7        user="app",
8        password="secret",
9    )
10    try:
11        cur = conn.cursor()
12        cur.execute("SHOW DATABASES LIKE %s", (db_name,))
13        return cur.fetchone() is not None
14    finally:
15        conn.close()
16
17print(database_exists("app_db"))

That pattern is much more reliable for provisioning or startup checks.

Shell Automation Example

The same idea works from the MySQL CLI.

mysql -u app -p -e "SHOW DATABASES LIKE 'app_db';"

If you want a cleaner machine-readable result, query the count instead.

mysql -N -u app -p -e "SELECT COUNT(*) FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME='app_db';"

That is useful in automation scripts that create the database only when needed.

Think About What Check You Actually Need

In production systems, the real question is often not only "does the database exist." It may actually be one of these:

• should the startup script create it if missing
• should the application fail fast if the environment is broken
• should we verify migrations and tables instead of only schema existence

A visible schema name does not guarantee the application is ready. The database may exist while still missing tables, privileges, or migrations.

So existence checks are best placed near the action that follows from them.

Permission Effects Matter

Because MySQL filters metadata by account visibility, an existence query depends on who is asking. If an admin can see a schema but the application user cannot, the app-level existence check may still return false.

That is not necessarily a bug in the query. It may reflect a real privilege problem.

Common Pitfalls

Connecting directly to the target schema before checking whether it exists is the most common implementation mistake.

Another common mistake is assuming that a missing result always means the schema does not exist, without considering user permissions.

Using a database existence check when the real need is an application-readiness check also causes confusion. Existence is not the same as usability.

Finally, avoid running repeated metadata checks in hot paths when one startup-time verification is enough.

Summary

• 'SHOW DATABASES LIKE 'name' is the quickest manual existence check in MySQL'
• 'INFORMATION_SCHEMA.SCHEMATA is useful for explicit SQL and automation'
• in application code, connect to the server first, not to the target schema
• remember that permissions affect what appears to exist
• in production, database existence is often only one part of a broader readiness check