ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes
ID: database/mysql-max-allowed-packet
Version Compatibility
| Version | Status | Introduced | Deprecated | Notes |
|---|---|---|---|---|
| 8 | active | — | — | — |
Root Cause
A query or result set exceeds the max_allowed_packet limit (default 64MB in MySQL 8.0). This controls the maximum size of a single MySQL protocol packet. Commonly triggered by inserting large BLOBs, bulk INSERT statements with many rows, or SELECT queries returning very large text/blob columns.
genericWorkarounds
-
95% success Increase max_allowed_packet to accommodate your data size
Dynamic change (no restart): SET GLOBAL max_allowed_packet = 256*1024*1024; (256MB). Permanent in my.cnf: max_allowed_packet = 256M. New connections pick up the global value. Existing connections keep their session value. Also set in client tools: mysql --max-allowed-packet=256M.
-
88% success Break large operations into smaller chunks
For bulk inserts, break into batches of 1000-5000 rows per INSERT statement. For large BLOBs, consider storing files on disk/S3 and saving only the path in MySQL. For mysqldump, use --max-allowed-packet=256M flag. For large SELECT results, use LIMIT/OFFSET pagination.
Dead Ends
Common approaches that don't work:
-
Setting max_allowed_packet on the client side only
75% fail
max_allowed_packet must be set on both the server and the client. The effective limit is the minimum of the two values. Setting it only on the client does nothing if the server limit is lower, and vice versa.
-
Setting max_allowed_packet to 1GB to never hit the limit
55% fail
max_allowed_packet is allocated per connection. With many concurrent connections, setting it very high can exhaust server memory. MySQL allocates the buffer dynamically but large packets require large allocations. A more targeted approach is to set it to the actual maximum expected data size plus a small margin.