云服务器
在 2核2GB 内存 的 Linux 服务器上运行 MySQL（尤其是 MySQL 5.7/8.0），资源非常紧张，盲目套用默认或生产级配置极易导致 OOM、频繁 swap、连接超时甚至服务崩溃。优化核心原则是：保守、精简、优先保障稳定性，牺牲部分功能换取内存可控性。
以下是关键且经过验证的优化配置建议（以 my.cnf 为例），适用于 MySQL 5.7+（推荐 8.0.33+ LTS 版本，内存管理更优）：
✅ 一、内存相关（重中之重！总内存占用务必控制在 ~1.2–1.4GB 以内）
[mysqld]
# —— 全局缓冲区（必须严格限制）——
innodb_buffer_pool_size = 640M # ⚠️ 关键！建议 60%~70% 可用内存（2G→约1.4G可用，留足系统+OS缓存）
innodb_buffer_pool_instances = 2 # 匹配CPU核数，减少争用（2核=2实例）
# —— 连接与线程（防OOM杀手）——
max_connections = 50 # 默认151，2G下50足够；按实际并发调整（如Web应用通常<30）
wait_timeout = 60 # 空闲连接60秒断开，快速释放内存
interactive_timeout = 60
# thread_cache_size = 4 # 可选，但2核下设为2~4即可（避免过度缓存）
# —— 查询缓存（MySQL 8.0已移除，5.7请禁用！）——
query_cache_type = 0 # ⚠️ 必须关闭！5.7中开启反而严重拖慢且耗内存
query_cache_size = 0
# —— 排序/临时表（高频内存消耗点）——
sort_buffer_size = 256K # 每连接分配，勿超512K（否则50连接=25MB+）
read_buffer_size = 128K
read_rnd_buffer_size = 256K
join_buffer_size = 256K
tmp_table_size = 32M # 内存临时表上限（同时影响 max_heap_table_size）
max_heap_table_size = 32M💡 内存估算示例（保守值）：
innodb_buffer_pool_size: 640MBmax_connections × (sort_buffer + join_buffer + read_buffer) ≈ 50 × 0.75MB ≈ 37.5MB- 其他全局开销（日志、字典缓存等）≈ 100–150MB
总计 ≈ 800–900MB，为 OS、SSH、其他进程（如Nginx/PHP）预留充足空间。
✅ 二、InnoDB 引擎优化（最常用引擎）
innodb_log_file_size = 64M # 日志文件大小（2G磁盘IO能力有限，64M平衡恢复时间与性能）
innodb_log_buffer_size = 2M # 日志缓冲区，够用即可
innodb_flush_log_at_trx_commit = 1 # ⚠️ 生产环境务必保持1（保证ACID），若可接受少量数据丢失可设2（仅限测试）
innodb_flush_method = O_DIRECT # 避免双重缓冲（Linux下推荐）
innodb_file_per_table = ON # 每表独立.ibd，便于空间回收和迁移
innodb_open_files = 400 # 避免"Too many open files"错误（配合ulimit -n 65535）
innodb_io_capacity = 100 # 机械硬盘/低配云盘设100；SSD可设200~400（根据磁盘IOPS调整）
innodb_io_capacity_max = 200✅ 三、安全与稳定性加固
# —— 防止OOM崩溃 ——
innodb_lock_wait_timeout = 30 # 锁等待超时（避免长事务阻塞）
innodb_rollback_on_timeout = OFF # 8.0.19+默认OFF，保持即可（避免回滚风暴）
# —— 日志精简（减少IO和磁盘占用）——
slow_query_log = OFF # 开发期可ON，生产环境建议OFF（或仅记录>2s）
long_query_time = 2.0
log_error = /var/log/mysql/error.log
log_error_verbosity = 2 # 仅记录WARNING及以上（减少日志量）
# —— 安全基线 ——
skip-networking = OFF # 保持ON需确保bind-address正确
bind-address = 127.0.0.1 # 如仅本地访问，绑定回环（更安全）
# 或 bind-address = 0.0.0.0 + 配合防火墙（如ufw allow from xx.xx.xx.xx）
# —— 表扫描防护（防慢SQL拖垮）——
max_allowed_packet = 16M # 足够应对大部分场景✅ 四、系统级协同优化（同样关键！）
# 1. 调整系统最大文件描述符（MySQL启动前设置）
echo 'mysql soft nofile 65535' | sudo tee -a /etc/security/limits.conf
echo 'mysql hard nofile 65535' | sudo tee -a /etc/security/limits.conf
# 并确保 /etc/pam.d/common-session 中有：session required pam_limits.so
# 2. 禁用swap（避免MySQL被swap杀死）
sudo sysctl vm.swappiness=1 # 仅在内存极度不足时使用swap
# 永久生效：echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf
# 3. 使用EXT4/XFS文件系统（避免Btrfs/ZFS在小内存下元数据开销大）
# 4. 定期清理二进制日志（如启用binlog）
# SET GLOBAL binlog_expire_logs_seconds = 259200; # 3天（MySQL 8.0.28+）✅ 五、必须做的配套措施（不配配置等于白配）
| 措施 | 说明 |
|---|---|
| ✅ 启用监控 | 用 mysqladmin extended-status 或 pt-mysql-summary 查看 Threads_connected, Innodb_buffer_pool_read_requests 等指标；重点关注 Innodb_buffer_pool_reads（物理读）是否突增（说明buffer不足） |
| ✅ 定期分析慢查询 | mysqldumpslow -s t /var/log/mysql/slow.log 或用 pt-query-digest |
| ✅ 索引优化 | EXPLAIN 每个核心SQL，确保 WHERE/JOIN 字段有索引；避免 SELECT *、LIKE '%xxx' |
| ✅ 应用层连接池 | PHP用 PDO::ATTR_PERSISTENT，Python用 SQLAlchemy 连接池，避免频繁创建连接 |
| ✅ 数据归档 | 老数据（如日志表）定期 DELETE 或 PARTITION BY RANGE，减小单表体积 |
❌ 绝对避免的配置（2G陷阱）
# × 错误示范（会导致OOM）：
innodb_buffer_pool_size = 1G # → 占用过大，系统无内存可用
key_buffer_size = 256M # MyISAM已淘汰，且浪费内存
table_open_cache = 2000 # 2G下应设为 400~600
innodb_log_file_size = 512M # 日志过大，启动慢且恢复时间长🔧 验证与调优命令
# 查看实际内存占用
ps aux --sort=-%mem | head -10
# 检查MySQL内存估算（运行中）
mysql -e "SHOW ENGINE INNODB STATUSG" | grep "BUFFER POOL"
# 查看当前连接与缓冲区使用
mysql -e "SHOW VARIABLES LIKE '%buffer%'; SHOW STATUS LIKE 'Threads_%';"
# 检查是否有swap使用
free -h && cat /proc/swaps📌 总结口诀
“一池两限三关闭”
- 一池：
innodb_buffer_pool_size控死在 600–700MB- 两限：
max_connections ≤ 50，tmp_table_size ≤ 32M- 三关闭：
query_cache_type=0、slow_query_log=OFF（生产）、symbolic-links=0（安全）
如业务增长，强烈建议升级至 4核4G 或迁移到云数据库（如阿里云RDS基础版） —— 小配置硬扛高负载，运维成本远高于硬件投入。
需要我帮你生成一份 完整可直接部署的 my.cnf 模板（含注释），或针对你具体的 MySQL版本/业务类型（如WordPress、Discuz、自研API） 做定制化配置，请随时告诉我！ 🚀