网站越来越慢，加了缓存、换了主题都没用？八成是数据库在拖后腿。MySQL优化听起来高深，其实80%的收益来自三板斧：揪出慢查询、补对索引、调好缓冲池。本文按实战顺序带你走一遍。
第一板斧：让慢查询无处遁形
优化的前提是定位。开启慢查询日志（my.cnf 的 [mysqld] 段）：
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 # 超过1秒即记录重启MySQL跑一天业务，用 mysqldumpslow -s t -t 10 /var/log/mysql/slow.log 列出最耗时的前10条SQL——它们就是你的优化对象清单。经验规律：拖垮全站的往往就是两三条SQL。
第二板斧：EXPLAIN与索引
对每条慢SQL执行 EXPLAIN SELECT ...，重点看两列：type为ALL表示全表扫描（重灾区）；rows是预估扫描行数，几十万行的扫描就是慢的根源。补索引的三原则：
- WHERE、JOIN、ORDER BY 涉及的列是建索引的候选；
- 多条件查询建联合索引，把区分度高的列放前面（最左前缀原则）；
- 索引不是越多越好——每个索引都拖慢写入，无用索引定期清理。
补完索引再EXPLAIN一次，type变为ref/range、rows骤降，就是立竿见影的胜利。WordPress站的postmeta大表查询、未加索引的插件自建表，是最常见的病灶。
第三板斧：核心参数调优
默认配置是为128M内存的古董机准备的，现代服务器必调三项（以8G内存专用数据库机为例）：
innodb_buffer_pool_size = 4G # 最重要！设为可用内存的50%—70%
innodb_log_file_size = 512M # 写密集业务加大
max_connections = 300 # 按业务并发调整buffer pool是InnoDB的内存缓存，设置得当能让热数据全部驻留内存，查询不碰磁盘。改完重启，用 SHOW ENGINE INNODB STATUS 观察缓冲池命中率，目标99%以上。
第四板斧：硬件层的天花板
软件调优做尽后，剩下的瓶颈在硬件：数据库是随机IO密集型负载，NVMe相比SATA SSD在这类场景常有数倍提升；虚拟化环境的IO抖动与CPU steal会直接反映为查询延迟毛刺——核心数据库业务建议放在物理独享的独立服务器或裸金属上，NVMe直通、无邻居干扰，P99延迟曲线才压得平。
优化验证清单
慢查询日志一周内新增为零、核心页面TTFB下降、EXPLAIN无全表扫描、缓冲池命中率99%+——四项达标，这轮优化即可收官。数据库优化是网站提速回报率最高的环节，从今天的慢查询日志开始吧。
