MySQL 慢查询优化实战记录

实战记录

MySQL 优化是运维必修课，分享几个实用经验：

1. 慢查询日志：打开 slow_query_log，配合 mysqldumpslow 分析，能快速定位问题 SQL
2. 索引优化：explain 看执行计划，避免全表扫描；联合索引遵循最左前缀原则
3. 参数调优：innodb_buffer_pool_size 通常设为物理内存的 60%-70%，不要贪多

遇到的问题

一次线上 MySQL 查询越来越慢，排查过程记录如下：

1. SHOW PROCESSLIST 发现有大量慢查询堆积
2. EXPLAIN 显示关键查询没用上索引，走了全表扫描
3. 补充联合索引后，查询时间从 3 秒降到 50ms

经验：新表建索引时就要考虑查询场景，不要等出问题了再补。

备份恢复

MySQL 备份的几种方案：mysqldump 适合小数据量，Xtrabackup 适合大数据量和在线备份。定期做恢复演练，确保备份可用。binlog 用于增量备份和时间点恢复。

参数调优

MySQL 参数调优的关键：innodb_buffer_pool_size 设为内存的 70% 左右，max_connections 根据实际需要调整，query_cache_type 在 MySQL 8.0 已废弃，用连接池代替。

遇到的问题

在 MySQL 慢查询优化实战记录 的实践中，遇到的最大的问题其实是环境差异。开发环境和生产环境不一致导致的各种奇怪问题，后来用容器化才解决了。所以环境一致性真的很重要，越早规范化越好。

避坑指南

记录一下过程中遇到的几个坑，大家引以为鉴：

第一，环境变量和配置文件里的路径，务必使用绝对路径，相对路径在定时任务里很容易出问题。

第二，权限问题无处不在，普通用户执行不了就查 sudo 和文件属主，别硬试。

第三，服务重启后要验证是否真的起来了，systemctl status 看一眼，别只看端口。

小结

技术问题大多是细节问题，耐心排查总能解决。希望这篇对大家有帮助，有问题欢迎楼下交流。

Mysql磁盘空间占太多了

终极大招 换更快的固态硬盘

学到了🤔