How to fix ERROR 2008: MySQL client ran out of memory in MySQL

MySQLINTERMEDIATEHIGHUpdated Dec 25, 2025· 153 views

The MySQL client runs out of memory while processing a query result set or allocating memory for operations. This error occurs when the result set is too large for available client memory, the client application is 32-bit, or when memory is poorly configured.

Quick fix

Fixes ERROR 2008: MySQL client ran out of memory

SELECT COUNT(*) FROM your_table WHERE your_conditions;
  1. Verify the query is actually necessary
  2. Use the --quick option with mysql CLI
  3. Use SELECT INTO OUTFILE to save results directly
  4. Reduce result set with LIMIT and pagination
mysql — error
SELECT COUNT(*) FROM your_table WHERE your_conditions;
ERROR 2008: MySQL client ran out of memory

What this error means

ERROR 2008 indicates the client-side MySQL process has exhausted available memory. Unlike server-side memory errors, this happens on the machine running the MySQL client (such as mysql CLI tool, Workbench, ODBC connector, or application server). The error usually includes details like "needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)". Common triggers include huge result sets (60,000+ rows with many columns), 32-bit application limitations, or memory limits imposed by the operating system. This is distinct from server "out of memory" errors and requires client-side solutions.

Typical symptoms

  • MySQL client crashes with "ERROR 2008" during query execution
  • Query results fail to retrieve despite the query being valid
  • MySQL Workbench or client tool becomes unresponsive when running large queries
  • ODBC or database connector crashes with memory allocation failure
  • Works with small result sets but fails with 50,000+ rows
  • Error message includes allocated bytes (e.g., "memory in use: 12481367 bytes")
  • Problem reproducible with specific queries but not others

Common causes

  1. Query returns too many rows or too many columns to fit in client memory
  2. Client is a 32-bit application with inherent 2-4 GB memory limit
  3. Operating system memory limits (ulimit) restrict available memory to the client
  4. Inefficient MySQL client driver fetches entire result set at once instead of streaming
  5. Very large rows with TEXT, BLOB, or JSON columns accumulating in client buffer
  6. Other processes competing for memory on the same machine
  7. ODBC connector misconfigured to buffer all results instead of using cursor-based retrieval

How to fix "ERROR 2008: MySQL client ran out of memory"

1Verify the query is actually necessary

First, review whether the query is correct and whether you truly need all rows. Run:

sql
SELECT COUNT(*) FROM your_table WHERE your_conditions;

If this returns 100,000+ rows, you likely need to add filters or pagination. Fewer rows = less memory on client side.

2Use the --quick option with mysql CLI

The --quick (or -q) flag tells the mysql client to use streaming result retrieval instead of buffering the entire result set:

bash
mysql -h localhost -u user -p --quick < large_query.sql > output.txt

This uses mysql_use_result() which fetches rows on-demand rather than all at once. This dramatically reduces client-side memory usage.

3Use SELECT INTO OUTFILE to save results directly

Instead of retrieving results into the client, save directly to the server file system:

sql
SELECT * FROM large_table
INTO OUTFILE '/var/lib/mysql-files/output.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n';

Then retrieve the file over SSH/SCP. This bypasses client memory entirely by processing on the server. Note: The file must be saved in the MySQL data directory (secure_file_priv setting).

4Reduce result set with LIMIT and pagination

Break large queries into smaller chunks:

sql
SELECT * FROM large_table
WHERE id > 0
LIMIT 10000;

-- Then in next iteration:
SELECT * FROM large_table
WHERE id > 10000
LIMIT 10000;

Or use offset-based pagination:

sql
SELECT * FROM large_table LIMIT 10000 OFFSET 0;
SELECT * FROM large_table LIMIT 10000 OFFSET 10000;

Process results in batches of 10,000-50,000 rows per query.

5Upgrade to 64-bit client if using 32-bit

Check if your MySQL client is 32-bit:

bash
# On Linux
file $(which mysql)
# Output: ELF 32-bit LSB shared object = 32-bit

# On Windows
# Check MySQL Workbench: Help > About

64-bit clients can address much more memory (terabytes vs 2-4 GB). Install the 64-bit version of your MySQL client, Workbench, or database driver:

bash
# Linux
sudo apt install mysql-client # defaults to 64-bit on modern systems

# macOS
brew install mysql-client

# Windows
# Download MySQL Community Server 64-bit installer from dev.mysql.com
6Configure ODBC cursor settings (for ODBC drivers)

If using ODBC (Excel, Power BI, certain BI tools), adjust result caching:

In ODBC Data Source Administrator (Windows) or .odbc.ini (Linux/macOS):

ini
[MySQL ODBC Driver]
CURSOR_TYPE=UseOdbc
USE_RESULT=1
PREFETCH=1000

Or in some drivers, enable:
- "Don't cache results of forward-only cursors"
- "Force use of forward-only cursors"

These settings use streaming instead of buffering the entire result set.

7Increase system memory limits

Check and increase the memory limit your OS allows for the mysql process:

bash
# Check current limits
ulimit -a

# Increase heap size (temporary, until reboot)
ulimit -v unlimited

# For persistent changes, edit /etc/security/limits.conf (Linux):
* hard memlock unlimited
* soft memlock unlimited

However, this is a temporary workaround. The root issue is the query/result set being too large.

8Use mysqldump with --quick for large exports

If backing up or exporting data, mysqldump with --quick streams results:

bash
mysqldump -h localhost -u user -p --quick --single-transaction \
  --routines --triggers large_database > backup.sql

The --quick flag (default with mysqldump) uses mysql_use_result() to avoid buffering. Always include --single-transaction for InnoDB to maintain consistency without table locks.

Advanced notes

This error is client-side, not server-side. The MySQL daemon itself has memory available, but the client process (whether mysql CLI, Workbench, an ODBC driver, or your application) ran out. This is different from ERROR 1037 ("Out of memory; restart server"), which means the server itself exhausted memory. For large data operations (terabytes of backup/restore), consider using non-traditional approaches: MySQL Shell's dump utilities with parallel threading, Percona Backup for MySQL (PBM) which is more efficient than mysqldump, or cloud-native solutions like AWS Database Migration Service. If this error occurs in application code (Node.js, Python, PHP), check if your connection pool or database driver is configured for streaming results rather than buffering. For example, in Node.js mysql2, use connection.query() with streaming instead of connection.execute() with all results.

Frequently asked questions

What does "ERROR 2008: MySQL client ran out of memory" mean?
ERROR 2008 indicates the client-side MySQL process has exhausted available memory. Unlike server-side memory errors, this happens on the machine running the MySQL client (such as mysql CLI tool, Workbench, ODBC connector, or application server). The error usually includes details like "needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)".
How do I fix "ERROR 2008: MySQL client ran out of memory"?
The MySQL client runs out of memory while processing a query result set or allocating memory for operations. This error occurs when the result set is too large for available client memory, the client application is 32-bit, or when memory is poorly configured.
What causes "ERROR 2008: MySQL client ran out of memory"?
Query returns too many rows or too many columns to fit in client memory Client is a 32-bit application with inherent 2-4 GB memory limit Operating system memory limits (ulimit) restrict available memory to the client
Is the "ERROR 2008: MySQL client ran out of memory" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading