S4-8G 上跑 MySQL 的参数建议

发布时间:2025-12-05 21:22

8G 内存跑 MySQL，参数要按可用内存规划，照搬默认值等于浪费一半资源，也有些参数改了反而添乱，下面给一套验证过、可以直接抄的基线。 一、内存分配原则 先给系统和开销预留 1.5G 左右，剩下的分给 MySQL：innodb_buffer_pool_size 设 5G 是常见起点，这是最重要的参数，决定热点数据有多少能常驻内存。连接相关内存按连接数乘以单个连接开销估算，max_connections 先设 300，中小应用够用。预留的 1.5G 不是随便给的：系统、备份任务、监控脚本都要内存，预留不足的后果是备份一跑就触发 swap，全库变慢还查不出原因。 二、关键参数示例 配置文件里的核心段： [mysqld] innodb_buffer_pool_size = 5G max_connections = 300 innodb_log_file_size = 512M slow_query_log = ON long_query_time = 1 改完 systemctl restart mysqld，用 SHOW VARIABLES LIKE 'innodb_buffer_pool_size' 确认已加载。改动逐条记录，和日期放一起，回溯时不用猜。 三、慢日志的用法 慢日志开了要有人看，建议固定在每天早上扫一遍：每天用 mysqldumpslow -s t /var/log/mysql/slow.log 这类命令摘出最慢的几条，加索引或改写语句。慢查询是性能劣化的前兆，放任不管迟早全站变慢。抓到的语句先跑 EXPLAIN 看执行计划走没走索引，多数慢查询一个索引就解决。慢日志文件本身也要配轮转，避免越写越大。 四、常见报错与验证 Too many connections：先查应用连接池是否泄漏、有没有慢查询占着连接不放，再考虑调上限；内存告急：buffer pool 别贪大，系统预留必须留够，挤到 swap 反而更慢。参数基线每半年回顾一次，业务涨了水位会说话，buffer pool 该加就加；同时盯住磁盘，数据和索引的增长最终都落在盘上。日常验证用 mysqladmin status 看连接与负载，配合 free -m 看水位，两条曲线稳住就没事。有条件再加一层 pt-query-digest 之类的分析工具，慢日志的价值能榨得更干。 参数调优是持续动作，先立基线再按监控微调，一次改十个参数等于给自己挖坑。整套基线落地后，8G 机器可以稳稳支撑中型业务，余量还够应对日常波动。