上一篇
场景引入:
凌晨3点,你的手机突然疯狂震动——线上订单系统卡死了!运维同事甩来一句“MySQL扛不住了”,而你盯着监控里CPU 100%的曲线和慢查询日志里十几秒的SQL,头皮发麻,别慌,今天我们就拆解MySQL的“控制中枢”my.cnf
,让你的数据库从“老牛拉车”变“高铁飙车”。
/etc/my.cnf
或/etc/mysql/my.cnf
my.ini
mysql --help | grep "my.cnf"
MySQL会按顺序加载以下文件(后者覆盖前者):
/etc/my.cnf → /etc/mysql/my.cnf → ~/.my.cnf
踩坑提醒:修改后务必重启服务生效:systemctl restart mysqld
[mysqld] max_connections = 500 # 默认151,根据业务调整 wait_timeout = 300 # 非交互连接超时(秒) interactive_timeout = 600 # 交互式连接(如命令行)
场景建议:电商大促期间可临时调高max_connections
,但注意每个连接消耗约4MB内存。
innodb_buffer_pool_size = 4G # 建议占物理内存的50-70% innodb_log_file_size = 256M # 事务日志大小(太大恢复慢) query_cache_size = 0 # MySQL 8.0已移除,老版本建议关闭
性能对比:将innodb_buffer_pool_size
从1G调到4G,某电商系统QPS提升210%。
innodb_io_capacity = 2000 # SSD建议2000-4000 innodb_flush_neighbors = 0 # SSD必关,HDD可开 innodb_file_per_table = ON # 每个表独立表空间
血泪教训:某公司未开启innodb_file_per_table
,导致系统表空间膨胀到500GB难以维护。
slow_query_log = 1 slow_query_log_file = /var/log/mysql-slow.log long_query_time = 1 # 超过1秒的记录 log_queries_not_using_indexes = 1 # 捕获无索引查询
诊断技巧:用mysqldumpslow
工具分析慢日志,比如统计最慢的10条SQL:
mysqldumpslow -s t -t 10 /var/log/mysql-slow.log
innodb_thread_concurrency = 0 # 0表示无限制(8核以上建议) thread_cache_size = 32 # 线程缓存数量 table_open_cache = 4000 # 表缓存(避免频繁开表)
innodb_read_io_threads = 8 innodb_write_io_threads = 4 read_buffer_size = 2M
innodb_flush_log_at_trx_commit = 2 # 牺牲部分持久性换性能 sync_binlog = 1000 # 每1000次同步binlog innodb_doublewrite = 0 # 仅当磁盘有掉电保护时禁用
sysbench
模拟真实流量 SHOW GLOBAL STATUS
变化 Threads_connected
、Innodb_row_lock_waits
等指标 最后忠告:没有“万能配置”,只有适合业务的配置,某社交平台曾盲目套用大厂参数,结果因join_buffer_size
设置过大导致OOM崩溃。—调优是门艺术,数据说话才是王道!
本文由 图门沈然 于2025-08-02发表在【云服务器提供商】,文中图片由(图门沈然)上传,本平台仅提供信息存储服务;作者观点、意见不代表本站立场,如有侵权,请联系我们删除;若有图片侵权,请您准备原始证明材料和公证书后联系我方删除!
本文链接:https://vps.7tqx.com/wenda/510927.html
发表评论