MySQL 启动失败报 Cannot allocate memory
怎么办
这通常不是系统真没内存，而是 MySQL 尝试分配的内存超出了内核限制（比如
vm.overcommit_memory=2下严格检查），或被 cgroup/容器限制了。先确认真实瓶颈：
dmesg -T | grep -i "out of memory"看是否被 OOM killer 杀过；
cat /proc/meminfo | grep -E "MemFree|MemAvailable"查剩余可用内存。 若在 Docker 中，检查是否设了过小的
--memory或
mem_limit，MySQL 的
innodb_buffer_pool_size必须小于该限制（建议 ≤ 50% 容器内存） 若在 systemd 管理下，检查
MemoryLimit或
LimitAS是否设得太低，需在 service 文件中显式放宽 临时绕过：运行
echo 1 > /proc/sys/vm/overcommit_memory（仅测试用，不推荐生产）
innodb_buffer_pool_size
设多大才安全
这是 MySQL 最吃内存的参数，设太高会导致系统 swap 频繁甚至僵死，设太低则磁盘 I/O 暴涨。它不是“越大越好”，而是要和实际数据集、并发压力、系统角色匹配。
专用数据库服务器：可设为物理内存的 50%–75%，但必须保留至少 2GB 给 OS + 其他进程（如备份脚本、监控 agent） 混合部署（如和 Web 服务同机）：建议 ≤ 25%，优先保 PHP/Python 进程不被 OOM 数据量远小于内存时（比如 10GB 数据配 64GB 内存），没必要塞满，innodb_buffer_pool_size = 12G足够，多余内存对性能无增益 动态调整后需重启 MySQL（8.0.22+ 支持在线调大，但仅限部分场景，仍建议停机操作）
哪些配置会悄悄吃掉大量内存
除了 buffer pool，以下参数在高并发或不当配置下极易引发内存雪崩：
sort_buffer_size和
read_buffer_size：每个连接独占一份，设成 4M 且有 200 并发连接 → 直接占用 1.6GB，应保持默认（256K / 128K）或按需微调
tmp_table_size和
max_heap_table_size：两者取小值决定内存临时表上限，设太大（如 512M）+ 多个复杂 GROUP BY 查询 → 内存临时表堆积，触发磁盘临时表或 OOM
thread_cache_size影响的是线程对象开销，本身不大，但设过高（如 32）会增加上下文切换压力，一般 4–16 足够 插件如
query_response_time或审计日志（
audit_log）开启后也会持续驻留内存，不用就禁用
如何验证当前内存分配是否合理
光看配置没用，得看运行时真实行为。重点查三类指标：
用SHOW ENGINE INNODB STATUS\G查
Buffer pool hit rate：长期低于 95% 表示 buffer pool 不够或查询模式异常（如全表扫描太多） 执行
SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;（需启用 performance_schema），看哪些分配器占内存最多，常发现
sql/JOIN_CACHE或
innodb/buf_buf_pool异常偏高 监控
Threads_connected和
Threads_created差值：若后者持续增长，说明
thread_cache_size不足，频繁创建销毁线程也会抖动内存 用
pmap -x $(pgrep mysqld)查进程实际 RSS，对比
innodb_buffer_pool_size+ 连接数 × 各 buffer 值，若 RSS 显著更高，大概率有内存泄漏（如老版本 InnoDB 插件 bug）或未释放的 prepare statement
真正难处理的是“内存缓慢增长不释放”——常见于长连接未 close、预编译语句未 deallocate、或使用了
innodb_use_sys_malloc=OFF且 jemalloc 版本有缺陷。这种问题不会立刻崩溃，但几周后必然 OOM。
