1G内存服务器运行MySQL必须严格调优：innodb_buffer_pool_size设为128M～256M，禁用查询缓存和Performance Schema，tmp_table_size与max_heap_table_size统一为32M，各连接缓冲区限256K以内，max_connections不超60，并禁用swap、调高ulimit。
1G 内存服务器上跑 MySQL，不调 my.cnf 几乎必然 OOM 或响应卡顿——系统本身要占 200–300MB，MySQL 默认配置（尤其 innodb_buffer_pool_size）在多数发行版里仍按 4GB+ 机器设，直接照搬会抢光内存。
innodb_buffer_pool_size 必须砍到 128M～256M
这是 MySQL 内存占用的“大头”，默认可能设成 128MB 甚至更高，但在 1G 机器上，它不能超过物理内存的 25%。超了不仅没收益，还会触发系统频繁 swap，甚至被 OOM Killer 直接干掉进程。
-
innodb_buffer_pool_size = 128M是 1G 机器最稳妥的起点；若只跑单个轻量 WordPress 或小后台，可试256M，但必须同步压低其他缓冲区 - 确认值已生效：
SELECT @@innodb_buffer_pool_size;返回的是字节数，134217728 = 128MB - 别碰
innodb_buffer_pool_instances：小内存下设多实例反而增加开销，保持默认（通常是 1）即可 - 改完必须重启 MySQL，
SET GLOBAL对该参数无效（MySQL 5.7+ 虽支持在线调整，但 1G 机器上 chunk size 往往不匹配，容易静默截断）
禁用或归零所有非必要缓存
查询缓存（query_cache_size）在高并发低重复场景下是负优化，锁争用比收益更致命；临时表限制不统一则易触发磁盘落盘，拖慢排序和 GROUP BY。
- 彻底关闭查询缓存：
query_cache_type = 0+query_cache_size = 0（MySQL 5.7 及以前有效；8.0 已移除，但宝塔默认装的多是 5.7） -
tmp_table_size和max_heap_table_size必须严格相等，建议统一设为32M：再大，单个复杂查询就可能吃掉上百 MB；再小，Created_tmp_disk_tables比率飙升，性能断崖下跌 - 关掉 Performance Schema：
performance_schema = off——它在 1G 机器上默认启用，默默吃掉 30–50MB 内存
每个连接的 buffer 要按“毫秒级”精算
sort_buffer_size、join_buffer_size 这类参数不是全局总和，而是**每个连接独占**。设成 2MB，100 个连接就是 200MB——对 1G 机器不可接受。
-
sort_buffer_size = 256K（够应付绝大多数 ORDER BY）、join_buffer_size = 256K、read_buffer_size = 128K -
max_connections别盲目设高，100是安全上限；实际用不到这么多，可进一步压到50或60 - 如果应用层用了连接池（如 PHP 的 pdo_mysql persistent），更要严控
max_connections，避免连接堆积 - 这些参数可在线动态设置（
SET SESSION sort_buffer_size = 262144;），适合临时诊断某条慢查询是否因内存不足被迫落盘
别漏掉系统级配合动作
MySQL 配置再紧，OS 层没配合也白搭。1G 机器上，swap 不是备选方案，而是性能杀手。
- 永久禁用 swap：
sudo sysctl vm.swappiness=0，并写入/etc/sysctl.conf；否则 MySQL 稍微内存紧张就会疯狂 swap，IO 卡死 - 检查
ulimit -n：确保文件描述符足够，open_files_limit = 65535在my.cnf里配了也没用，得先在系统层放开（/etc/security/limits.conf） - Redis 若共存，务必限制其内存：
maxmemory 256mb+maxmemory-policy allkeys-lru，否则它和 MySQL 抢内存时，往往 MySQL 先被 kill
真正难的不是参数数字本身，而是理解每个值背后对应的内存乘法效应——比如 sort_buffer_size × max_connections 这种隐式叠加，很容易被忽略。调完别只看启动成功，盯三天 free -h 和 SHOW STATUS LIKE 'Created_tmp%'; 才算落地。
