MySQL Error 1264

Error number

1264

SQLSTATE

22003

Symbol

ER_WARN_DATA_OUT_OF_RANGE

Product

MySQL Server

Versions

MySQL 5.7, 8.0 and 8.4 (an error in strict mode, a warning without it)

Category

Data Values & Strict Mode

Last reviewed

24 October 2026

What it means

Error 1264 means a number is too large, too small or negative for the column's data type, so in strict mode MySQL rejected it instead of storing a clipped value.

Every numeric column has a fixed range. A signed TINYINT holds -128 to 127, an INT about plus or minus 2.1 billion, an UNSIGNED column nothing below 0, and DECIMAL(5,2) at most 999.99 (five digits in total, two after the point). When an INSERT, UPDATE, LOAD DATA or ALTER TABLE would store a value outside that range, strict mode stops the statement with 1264 and names the column and the row number within the statement. A value that is rounded to fit can also overflow: 999.999 rounds to 1000.00, which does not fit DECIMAL(5,2).

Without strict mode MySQL clips the value to the nearest end of the range and only warns, so 300 is stored as 127 and -5 as 0 in an UNSIGNED column. That is silent data corruption; keep strict mode on. Overflow inside an expression, such as qty - 10 on an UNSIGNED column going below zero, is error 1690 rather than 1264. See SQL data types explained for choosing column types.

Common causes

• The column type is too small for real data: a TINYINT for stock levels, an INT for phone numbers, ids from another system or file sizes in bytes.
• A DECIMAL has too few digits before the point, for example DECIMAL(5,2) for prices that can reach 1000 or more.
• A negative number is written to an UNSIGNED column, often a refund, an adjustment or a bug in the calculation.
• An UPDATE multiplies or adds to a value until it no longer fits, for example SET stock = stock * 20.
• ALTER TABLE changes a column to a smaller type while some rows hold values that do not fit.

Diagnose it

Read-only These statements only read metadata (information_schema, performance_schema and SHOW statements) or your own data. They do not change data, privileges or configuration, so they are safe to run first.

SELECT column_name, column_type, numeric_precision, numeric_scale
FROM information_schema.columns
WHERE table_schema = DATABASE()
  AND table_name = 'products'
ORDER BY ordinal_position;

SELECT id, qty
FROM staging_products
WHERE qty < 0 OR qty > 65535;

SELECT id, total
FROM orders
WHERE total NOT BETWEEN -32768 AND 32767;  -- the SMALLINT range

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

ALTER TABLE products
  MODIFY stock INT NOT NULL DEFAULT 0,
  MODIFY price DECIMAL(10,2);

ALTER TABLE phones MODIFY phone VARCHAR(20);

UPDATE orders SET total = 32767 WHERE id = 1;  -- only if the business agrees this value is correct
ALTER TABLE orders MODIFY total SMALLINT;

Examples

A value too large for a TINYINT

CREATE TABLE products (
    id    INT PRIMARY KEY,
    stock TINYINT  -- -128 to 127
);

INSERT INTO products (id, stock) VALUES (1, 300);

ERROR 1264 (22003): Out of range value for column 'stock' at row 1

A price with too many digits for DECIMAL(5,2)

CREATE TABLE products (
    id    INT PRIMARY KEY,
    price DECIMAL(5,2)  -- at most 999.99
);

INSERT INTO products (id, price) VALUES (2, 1234.50);

ERROR 1264 (22003): Out of range value for column 'price' at row 1

A phone number stored in an INT

CREATE TABLE phones (
    id    INT PRIMARY KEY,
    phone INT  -- at most 2147483647
);

INSERT INTO phones VALUES (1, 447700900123);

ERROR 1264 (22003): Out of range value for column 'phone' at row 1

Shrinking a column that holds larger values

CREATE TABLE orders (id INT PRIMARY KEY, total INT);
INSERT INTO orders VALUES (1, 50000);

ALTER TABLE orders MODIFY total SMALLINT;  -- SMALLINT stops at 32767

ERROR 1264 (22003): Out of range value for column 'total' at row 1

How to prevent it

Size numeric columns for the largest realistic value, not today's data: INT or BIGINT for counters and ids, DECIMAL with enough digits for money, and VARCHAR for phone numbers and other codes. Use UNSIGNED only where a negative value is truly impossible, and remember that calculations on it can still go negative.

Validate numbers at the application boundary and check staging data against the target range before loading. Keep strict mode on so an out-of-range value fails loudly instead of being clipped to the end of the range.

Common questions

Learn more on CodeWithSQL

• SQL data types explained
• SQL constraints explained

Official documentation

• MySQL 8.0 server error message reference
• Out-of-range and overflow handling
• Integer types (exact value)
• Fixed-point types (DECIMAL, NUMERIC)

Last technically reviewed 24 October 2026; examples and diagnostics run on MySQL 8.0.46. Message templates checked against the server's error catalogue (perror) for that version.