innodb_buffer_pool_size必须设为128m～256m以适配1g服务器，因其是启动时固定分配的内存块，超限会触发oom killer；需配合压低tmp_table_size等参数并重启生效。
innodb_buffer_pool_size 必须砍到 128M～256M
这是最直接有效的降内存手段。默认配置在多数发行版里仍按 4GB+ 机器设，innodb_buffer_pool_size 常为 128MB 或更高——对 1G 服务器已是危险值。它不是“建议值”，而是 MySQL 启动时就 malloc 的固定内存块，超了就会触发 Cannot allocate memory 或被 OOM Killer 杀掉进程。
实操建议：
-
innodb_buffer_pool_size = 128M是 1G 机器最稳妥起点；若只跑单表小应用（如轻量后台），可试256M，但必须同步压低其他缓冲区 - 确认生效：执行
SELECT @@innodb_buffer_pool_size;，返回134217728表示 128MB - 该参数不支持 SET GLOBAL 在线生效（尤其小内存下 chunk size 不匹配易静默截断），改完必须重启 mysqld
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% 就说明频繁落盘 - 禁用查询缓存：
query_cache_type = 0+query_cache_size = 0（MySQL 5.7 及以前），避免锁争用拖慢并发
每个连接的 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） - 关掉非必要功能：
performance_schema = off（默默吃 30–50MB）、skip_log_bin（无主从时禁用 binlog）
别碰 innodb_buffer_pool_instances 和 innodb_log_file_size
小内存下多实例反而增加 mutex 开销，innodb_buffer_pool_instances 保持默认（通常是 1）即可。而 innodb_log_file_size 默认 48M，在 1G 机器上刷脏页压力大、恢复慢，但调太高又加重写放大。
实操建议：
- 设为
innodb_log_file_size = 64M（比默认略高，平衡 recovery 时间与写入节奏） - 不要设
innodb_file_per_table = OFF来“省小文件”，它在小内存下反而减少碎片压力，但前提是表不多；若表超百，保留 ON 更稳 - 禁用 swap：
sudo swapoff -a，并确保/etc/fstab中注释掉 swap 行——swap 是低配 MySQL 的慢性毒药
free -m 看系统真实剩余内存，再结合 SHOW STATUS LIKE 'Created_tmp%' 和 SHOW PROCESSLIST 观察状态，否则“设了等于没设”。
