MySQL服务器内存有限时InnoDB如何调优

innodb_buffer_pool_size必须设为128M～256M，因其是MySQL启动时malloc的固定内存块，超限会触发OOM Killer；需配合压低tmp_table_size等参数并重启生效。

1G 内存服务器上，innodb_buffer_pool_size 必须设为 128M～256M，否则 MySQL 启动就可能被 OOM Killer 杀掉。

为什么 innodb_buffer_pool_size 是首要调优项

它不是“建议缓存大小”，而是 MySQL 启动时就 malloc 的一块固定内存块。默认配置（如 128MB 或更高）在多数发行版中仍面向 4GB+ 机器，对 1G 服务器属于危险值。超限后系统会直接报 Cannot allocate memory，或触发 OOM Killer 终止 mysqld 进程。

实操建议：

1. innodb_buffer_pool_size = 128M 是 1G 机器最稳妥起点；若仅跑单表小应用（如轻量后台），可试 256M，但必须同步压低其他缓冲区
2. 该参数不支持 SET GLOBAL 在线生效——尤其小内存下 chunk size 不匹配易静默截断，改完必须重启 mysqld
3. 确认生效：执行 SELECT @@innodb_buffer_pool_size;，返回 134217728 表示 128MB

tmp_table_size 和 max_heap_table_size 必须严格相等

这两个参数控制内存临时表上限。MySQL 实际以二者中较小值为准，但逻辑混乱会导致 GROUP BY 或 ORDER BY 悄悄落到磁盘，出现 Using temporary; Using filesort，性能断崖下跌。

实操建议：

1. 统一设为 tmp_table_size = 32M 和 max_heap_table_size = 32M（1G 机器上限）
2. 再大，单个复杂查询就可能吃掉上百 MB；再小，Created_tmp_disk_tables / Created_tmp_tables 比率会飙升，监控时 >10% 就说明频繁落盘

每个连接的 buffer 要按“连接数 × 单值”精算

sort_buffer_size、join_buffer_size、read_buffer_size 这些不是全局总和，而是每个连接独占。设成 2MB，60 个连接就是 120MB——对 1G 机器不可接受。

实操建议：

1. sort_buffer_size = 256K、join_buffer_size = 256K、read_buffer_size = 128K
2. thread_stack = 192K（低于此值可能栈溢出）
3. max_connections = 60（1G 机器硬上限，再高极易 OOM）
4. 禁用查询缓存：query_cache_type = 0 + query_cache_size = 0（MySQL 5.7 及以前），避免锁争用拖慢并发

最容易被忽略的是：所有这些参数修改后必须重启 mysqld 才能真正生效，且不能只看配置文件写对了——要进 MySQL 执行 SELECT @@variable_name 确认运行时值。小内存环境下，任何“看起来无害”的 buffer 增加都可能成为压垮系统的最后一根稻草。