MySQL Error 1153

Error number

1153

SQLSTATE

08S01

Symbol

ER_NET_PACKET_TOO_LARGE

Product

MySQL Server

Versions

MySQL 5.7, 8.0 and 8.4 (server default max_allowed_packet 64 MB in 8.0; largest possible packet 1 GB)

Category

Connections & Network

Last reviewed

24 October 2026

What it means

Error 1153 means the server received a single packet, usually one SQL statement, larger than its max_allowed_packet limit, so it rejected it and closed the connection.

Client and server exchange data in packets. A packet is a single SQL statement sent to the server, a single row sent back to the client, or one binary log event sent to a replica. The server refuses any packet larger than max_allowed_packet (64 MB by default in MySQL 8.0), returns 1153 and closes the connection, because it treats an oversized packet as a sign that something went wrong. That is why the error usually comes with a lost connection: the next statement on that connection fails with 2006, and some clients report 2013 instead of 1153 in the first place.

The client side has its own limit for what it receives: the mysql client defaults to 16 MB and mysqldump to 24 MB, while the C client library's built-in default is 1 GB. So a big value may be refused by the server on the way in (1153) or by the client on the way out (client error 2020). The session value of max_allowed_packet is read-only; only the global value, set at runtime or at startup, changes the server limit.

Common causes

• A single INSERT or UPDATE carries a large BLOB or TEXT value, such as a file, an image or a large JSON document.
• A multi-row INSERT built by the application or an ORM grows past the limit (thousands of rows in one statement).
• A dump made with large extended INSERT statements is loaded into a server with a smaller max_allowed_packet than the source.
• A query returns a row bigger than the client's limit, which the client reports as its own error 2020 rather than 1153.

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.

SHOW VARIABLES LIKE 'max_allowed_packet';
SELECT @@GLOBAL.max_allowed_packet AS global_bytes,
       @@SESSION.max_allowed_packet AS this_session_bytes;

SELECT COUNT(*) AS documents,
       MAX(LENGTH(body)) AS largest_bytes,
       ROUND(MAX(LENGTH(body)) / 1048576, 1) AS largest_mb
FROM documents;

SELECT error_number, error_name, sum_error_raised, first_seen, last_seen
FROM performance_schema.events_errors_summary_global_by_error
WHERE error_number = 1153;

SHOW GLOBAL STATUS LIKE 'Aborted_clients';

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.

INSERT INTO order_lines (order_id, line_no, product_id, qty) VALUES
  (10, 1, 501, 2),
  (10, 2, 502, 1);  -- send batches like this, not one statement with every row

-- mysqldump --max-allowed-packet=256M shop > shop.sql
-- mysql --max-allowed-packet=256M shop < shop.sql

SET PERSIST max_allowed_packet = 268435456;  -- 256 MB, for new connections

# or in my.cnf
[mysqld]
max_allowed_packet = 256M

Examples

One statement larger than the server limit (PHP mysqli)

Captured with PHP 8.2 mysqli (mysqlnd) against MySQL 8.0.46 and shown in the client's ERROR format from errno, SQLSTATE and message. It is a race with the server closing the connection: in our runs the same statement gave 1153 most of the time and 2006 MySQL server has gone away sometimes. The statement is too large to store in the page, so the lab does not rerun it.

SHOW VARIABLES LIKE 'max_allowed_packet';  -- 67108864 (64 MB)

-- From PHP, one statement of about 70 MB:
-- $big = str_repeat('x', 70 * 1024 * 1024);
-- $mysqli->query("SELECT LENGTH('$big') AS len");

ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes

The connection is gone afterwards (PHP PDO)

Captured with PHP 8.2 PDO_MYSQL against MySQL 8.0.46: the first call raised SQLSTATE[08S01]: Communication link failure: 1153 Got a packet bigger than 'max_allowed_packet' bytes, and the next statement on the same connection failed with 2006 because the server had closed it. Not rerun by the lab (needs a 70 MB statement).

-- $pdo->query($seventyMegabyteStatement);  -- fails with 1153
$pdo->query('SELECT 1');

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

The mysql client reports the same problem as 2013

Captured with the mysql 8.0.46 client on Windows, with and without a raised client limit. The server counted the packet as error 1153 (visible in events_errors_summary_global_by_error), but this client only saw the closed connection. The manual mentions this: with some clients you get Lost connection to MySQL server during query instead.

-- big.sql holds one statement of about 70 MB:
-- mysql --max-allowed-packet=128M < big.sql
SELECT LENGTH('xxxx...about 70 MB of text...') AS len;

ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

How to prevent it

Design for bounded statements: batch bulk inserts, stream or chunk large files, and give servers that exchange dumps the same max_allowed_packet. Check the size of the largest values in BLOB, TEXT and JSON columns before a migration.

Because the client often sees 2006 or 2013 instead of 1153, watch the server side: error 1153 in performance_schema.events_errors_summary_global_by_error is the reliable sign that packets are too large.

Common questions

Learn more on CodeWithSQL

• Back up and restore with mysqldump
• Run MySQL in Docker

Official documentation

• Packet too large
• Server system variables (max_allowed_packet)
• mysqldump (--max-allowed-packet)
• MySQL server has gone away

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.