ERROR 1037 indicates MySQL has exhausted available memory, but the underlying cause can be insufficient RAM, too many file handles, corrupted table files, or memory buffer misconfiguration. This guide covers diagnosis and fixes.
MySQL ERROR 1037 (SQLSTATE HY001) occurs when the MySQL server cannot allocate memory for an operation. The error message often specifies the number of bytes needed (e.g., "needed 65528 bytes"). However, this error can be misleading—the actual root cause is frequently not memory exhaustion but rather too many file handles open, corrupted .frm or .par files, or queries consuming excessive temporary table memory. The server may also return this error when system swap space is unavailable or when memory buffers are misconfigured relative to available system RAM.
First, verify that your system actually has sufficient free memory and swap configured.
Linux:
free -h
# Output shows Mem and Swap usage
cat /proc/meminfo | grep -E 'MemFree|SwapFree'
# Check swap configuration
swapon --showmacOS:
vm_stat
# Shows free, inactive, and wired memory pages
# Check swap usage
ls -lh /var/vm/swap*If swap space is very low or zero, add swap or increase it before proceeding.
Too many open file handles is a common cause of ERROR 1037. Check if MySQL is hitting the system limit.
Check current limits:
# Current process limits
ulimit -n
# Should typically be 1024 or higher
# System-wide limits
cat /proc/sys/fs/file-max
cat /proc/sys/fs/file-nrIncrease file handle limits:
Edit /etc/security/limits.conf and add:
mysql soft nofile 65536
mysql hard nofile 65536
mysql soft nproc 65536
mysql hard nproc 65536Then restart MySQL:
sudo systemctl restart mysqlMemory buffers configured too large for available RAM is a frequent cause. Review your MySQL configuration file.
Locate your MySQL config:
mysql --help | grep 'Default options' -A 1
# Usually /etc/mysql/mysql.cnf, /etc/mysql/my.cnf, or /etc/my.cnfCheck current memory settings:
SHOW VARIABLES LIKE '%buffer%';
SHOW VARIABLES LIKE '%cache%';
SHOW VARIABLES LIKE '%pool%';Key settings to review and adjust:
1. InnoDB Buffer Pool (largest consumer):
# Rule of thumb: 50-80% of available RAM, never more than physical RAM
innodb_buffer_pool_size = 1G2. Per-thread buffers (multiply by max_connections):
sort_buffer_size = 2M # Used for ORDER BY, GROUP BY
read_buffer_size = 1M
read_rnd_buffer_size = 1M
join_buffer_size = 1M
tmp_table_size = 64M
max_heap_table_size = 64M3. Total memory estimate:
total = innodb_buffer_pool_size +
(sort_buffer_size * max_connections) +
(read_buffer_size * max_connections) +
(join_buffer_size * max_connections) +
(key_buffer_size) +
(query_cache_size) +
~500MB for OS and other overheadApply changes:
Edit your MySQL config file and adjust values, then restart:
sudo systemctl restart mysqlCorrupted .frm or .par files can trigger ERROR 1037 even when memory is available.
Check for corrupted tables:
# Navigate to MySQL data directory (usually /var/lib/mysql)
cd /var/lib/mysql
# Check for missing or corrupted files
# .frm = table definition
# .ibd = InnoDB data file (if using InnoDB)
# .par = partition definition
# Look for incomplete files or permission issues
ls -la your_database/ | grep -E '\.(frm|par)$'Repair tables:
-- Connect to MySQL and repair the suspected table
REPAIR TABLE table_name;
-- For InnoDB, use CHECK and OPTIMIZE
CHECK TABLE table_name;
OPTIMIZE TABLE table_name;
-- If that fails, use innochecksum (InnoDB only)
-- Stop MySQL firstFor missing .par files (partitioned tables):
The error "missing .par file" now returns a more descriptive message in MySQL 5.1.48+. If you have an older version, consider upgrading.
Some queries consume excessive temporary table memory and trigger ERROR 1037.
Identify problematic queries:
-- Enable slow query log if not already enabled
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
-- Or check the error log for patterns
SHOW VARIABLES LIKE 'log_error';Optimize queries that use ORDER BY or GROUP BY:
Instead of:
SELECT * FROM large_table
WHERE status = 'active'
ORDER BY created_at DESC
LIMIT 1000;Use:
-- Add indexes to avoid full scans and temporary table sorts
CREATE INDEX idx_status_created ON large_table(status, created_at DESC);
-- Use LIMIT to reduce result set
SELECT id, status, created_at FROM large_table
WHERE status = 'active'
ORDER BY created_at DESC
LIMIT 100;
-- For very large aggregations, consider materialized views or caching
SELECT status, COUNT(*) FROM large_table
GROUP BY status;Analyze query execution:
EXPLAIN FORMAT=JSON SELECT ... \G
-- Look for "Using temporary", "Using filesort" indicatorsToo many connections multiplies per-thread buffer usage. Reduce max_connections if not needed.
Check current setting:
SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';Reduce if necessary:
Edit your MySQL config:
# Default is often 151, reduce to match actual concurrent connections needed
max_connections = 100
# Also reduce thread cache to free memory
thread_cache_size = 8Then restart MySQL.
If you've made configuration changes or need to clear memory allocations immediately:
# Linux/Unix
sudo systemctl restart mysql
# Or using service
sudo service mysql restart
# Check it restarted successfully
sudo systemctl status mysql
# Or monitor the log
tail -f /var/log/mysql/error.logAfter restart, monitor for the error recurring. If it persists, the root cause is not temporary memory fragmentation.
For replication environments: Compare cluster sizing (Storage, Memory, CPU) between primary and secondary servers. A secondary with less memory will fail first.
Linux kernel memory overcommit: Check vm.overcommit_memory setting. A value of 1 allows memory overcommit, potentially causing OOM errors later.
cat /proc/sys/vm/overcommit_memory
# 0 = heuristic, 1 = always allow, 2 = never allowInnoDB background threads: Even at idle, InnoDB consumes memory. Multiple background threads (flushing, IO threads) each allocate buffers. Monitor with SHOW ENGINE INNODB STATUS;\G
Temporary table memory: Temporary tables created by queries (ORDER BY without index, large GROUP BY) first use memory (tmp_table_size), then spill to disk. Increase tmp_table_size carefully or add indexes to avoid temporary tables.
MySQL version: Older versions (pre-5.1.48) return ERROR 1037 for missing partition files instead of descriptive messages. Upgrade if running very old versions.
EE_WRITE (3): Error writing file
How to fix "EE_WRITE (3): Error writing file" in MySQL
CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters
How to fix "CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters" in MySQL
CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed
How to fix "CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed" in MySQL
ERROR 1146: Table 'database.table' doesn't exist
How to fix "ERROR 1146: Table doesn't exist" in MySQL
ERROR 1040: Too many connections
How to fix "ERROR 1040: Too many connections" in MySQL