Introduction

If you need to know whether a MySQL table contains a particular column, the usual solution is to query INFORMATION_SCHEMA.COLUMNS. That gives you a reliable metadata check and works well in migrations, deployment scripts, and defensive administration queries.

Use INFORMATION_SCHEMA.COLUMNS

The most common pattern is:

1SELECT COUNT(*) AS column_exists
2FROM INFORMATION_SCHEMA.COLUMNS
3WHERE TABLE_SCHEMA = 'app_db'
4  AND TABLE_NAME = 'users'
5  AND COLUMN_NAME = 'last_login_at';

If the count is greater than zero, the column exists. If it is zero, it does not.

This approach is reliable because INFORMATION_SCHEMA stores metadata for tables, columns, indexes, and other schema objects across the server.

Return a Simple Boolean-Style Result

When you want a one-row yes-or-no answer, EXISTS reads nicely:

1SELECT EXISTS (
2    SELECT 1
3    FROM INFORMATION_SCHEMA.COLUMNS
4    WHERE TABLE_SCHEMA = 'app_db'
5      AND TABLE_NAME = 'users'
6      AND COLUMN_NAME = 'last_login_at'
7) AS column_exists;

This returns 1 if the column exists and 0 if it does not.

For scripts and migration tools, this is often easier to consume than a raw count.

Why TABLE_SCHEMA Matters

Do not filter only by table name and column name. MySQL can have multiple databases on the same server, and the same table name may exist in more than one schema.

This part is essential:

TABLE_SCHEMA = 'app_db'

Without it, your query may report a column from the wrong database.

SHOW COLUMNS Is Fine for Manual Inspection

For ad hoc interactive work, SHOW COLUMNS is also useful:

SHOW COLUMNS FROM users LIKE 'last_login_at';

If a row is returned, the column exists. This is convenient in the MySQL client, but it is less flexible than INFORMATION_SCHEMA when you want reusable scripts or conditional logic.

Example in a Migration Workflow

Suppose you want to add a column only if it is missing. One way is to check first and then run the migration step:

1SELECT EXISTS (
2    SELECT 1
3    FROM INFORMATION_SCHEMA.COLUMNS
4    WHERE TABLE_SCHEMA = 'app_db'
5      AND TABLE_NAME = 'users'
6      AND COLUMN_NAME = 'last_login_at'
7) AS column_exists;

If the result is 0, then run:

ALTER TABLE users
ADD COLUMN last_login_at DATETIME NULL;

In modern MySQL versions, ALTER TABLE ... ADD COLUMN IF NOT EXISTS may be available depending on the exact operation and version, but INFORMATION_SCHEMA checks are still widely used because they are explicit and portable across tooling.

Application-Level Checks

Sometimes it is better not to do this dynamically in application request code at all. Repeated schema probing inside runtime logic can hide migration problems that should be handled during deployment. Schema checks are most appropriate in:

• migration scripts
• maintenance utilities
• install or upgrade steps
• database diagnostics

If an application requires a column to function, a failed migration is usually the real problem to solve.

Common Pitfalls

• Forgetting to filter by TABLE_SCHEMA and matching the wrong database.
• Using schema checks in hot application paths instead of fixing migrations.
• Assuming SHOW COLUMNS is the best option for automated scripts.
• Not handling permissions properly if the database user has restricted metadata access.
• Treating a column existence check as a substitute for versioned schema management.

Summary

• The standard MySQL solution is to query INFORMATION_SCHEMA.COLUMNS.
• Use EXISTS or COUNT(*) to determine whether a column is present.
• Always include TABLE_SCHEMA, TABLE_NAME, and COLUMN_NAME in the filter.
• 'SHOW COLUMNS ... LIKE ... is convenient for manual inspection.'
• Prefer using these checks in migrations and admin scripts rather than normal request-time logic.