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 进程。
实操建议：
-
innodb_buffer_pool_size = 128M是 1G 机器最稳妥起点；若仅跑单表小应用（如轻量后台），可试256M，但必须同步压低其他缓冲区 - 该参数不支持
SET GLOBAL在线生效——尤其小内存下 chunk size 不匹配易静默截断，改完必须重启mysqld - 确认生效：执行
SELECT @@innodb_buffer_pool_size;，返回134217728表示 128MB
tmp_table_size 和 max_heap_table_size 必须严格相等
这两个参数控制内存临时表上限。MySQL 实际以二者中较小值为准，但逻辑混乱会导致 GROUP BY 或 ORDER BY 悄悄落到磁盘，出现 Using temporary; Using filesort，性能断崖下跌。
实操建议：
- 统一设为
tmp_table_size = 32M和max_heap_table_size = 32M（1G 机器上限） - 再大，单个复杂查询就可能吃掉上百 MB；再小，
Created_tmp_disk_tables / Created_tmp_tables比率会飙升，监控时 >10% 就说明频繁落盘
每个连接的 buffer 要按“连接数 × 单值”精算
sort_buffer_size、join_buffer_size、read_buffer_size 这些不是全局总和，而是每个连接独占。设成 2MB，60 个连接就是 120MB——对 1G 机器不可接受。
实操建议：
-
sort_buffer_size = 256K、join_buffer_size = 256K、read_buffer_size = 128K -
thread_stack = 192K（低于此值可能栈溢出） -
max_connections = 60（1G 机器硬上限，再高极易 OOM） - 禁用查询缓存：
query_cache_type = 0+query_cache_size = 0（MySQL 5.7 及以前），避免锁争用拖慢并发
最容易被忽略的是：所有这些参数修改后必须重启 mysqld 才能真正生效，且不能只看配置文件写对了——要进 MySQL 执行 SELECT @@variable_name 确认运行时值。小内存环境下，任何“看起来无害”的 buffer 增加都可能成为压垮系统的最后一根稻草。
