Introduction

MySQL warnings are messages produced by a statement that completed, but not perfectly. They are easy to miss because the statement may still succeed, so the usual way to inspect them is to run SHOW WARNINGS immediately after the statement that generated them.

Use SHOW WARNINGS Right After the Statement

Warnings are associated with the most recent statement. That means the normal workflow is:

1. Run the SQL statement.
2. Immediately run SHOW WARNINGS.

Example:

1CREATE TEMPORARY TABLE demo (
2    name VARCHAR(3)
3);
4
5INSERT INTO demo (name) VALUES ('abcdef');
6SHOW WARNINGS;

If SQL mode allows truncation with a warning instead of an error, SHOW WARNINGS will display the warning level, numeric code, and message.

Count Warnings First if Needed

Sometimes you only want to know whether warnings happened before printing them.

SHOW COUNT(*) WARNINGS;

That returns the number of warnings from the last statement. If it is greater than zero, follow up with:

SHOW WARNINGS;

This is useful in scripts or manual debugging sessions where you want a quick signal before looking at the full messages.

Why Timing Matters

The biggest detail is that warnings belong to the immediately preceding statement. If you run another command first, you may replace the warning context and lose the original information.

For example, this is safe:

INSERT INTO demo (name) VALUES ('abcdef');
SHOW WARNINGS;

This is risky if the second statement itself changes the warning state:

INSERT INTO demo (name) VALUES ('abcdef');
SELECT * FROM demo;
SHOW WARNINGS;

If you care about the insert warning, inspect it before running unrelated statements.

Typical Cases That Generate Warnings

Warnings commonly come from:

• String truncation
• Implicit type conversion
• Use of deprecated syntax
• Data out of range with non-strict behavior
• Division by zero in permissive SQL modes

Here is another example:

SELECT CAST('12abc' AS UNSIGNED);
SHOW WARNINGS;

Depending on SQL mode, MySQL may return a numeric result while warning that the string could not be converted cleanly.

Application Code Considerations

If you are using MySQL from application code, the exact API for reading warnings depends on the client library. Some connectors surface warnings directly, while others require an explicit query after the main statement.

The database-side rule stays the same: warnings are part of statement execution state, so inspect them promptly if they matter to your workflow.

Warnings Versus Errors

Do not confuse a warning with an error.

• An error stops the statement.
• A warning means the statement ran, but MySQL detected something questionable.

In strict SQL modes, some operations that would normally produce warnings instead become errors. That is often desirable in production because it prevents silent data quality problems.

If many warnings are produced, MySQL lets you inspect them as rows, which makes them easier to script against than reading client-side status text. In interactive sessions, this is especially helpful because the warning count alone does not tell you whether the issue was truncation, conversion, deprecation, or something else entirely.

Common Pitfalls

The most common mistake is running SHOW WARNINGS too late. Warnings are tied to the most recent statement, so timing matters.

Another mistake is assuming no error means no issue. A statement can succeed and still have truncated data or type-conversion behavior you did not intend.

A third mistake is debugging warnings without checking SQL mode. Whether a condition becomes a warning or an error depends heavily on the server’s mode configuration.

Summary

• Use SHOW WARNINGS immediately after the statement that generated the warning.
• Use SHOW COUNT(*) WARNINGS when you first want a count.
• Warnings apply to the most recent statement, so do not run unrelated queries first.
• Warnings often reveal truncation, conversion, or deprecated behavior.
• Strict SQL modes can turn warning-producing operations into errors.