你有没有遇到过这种情况：网站突然变慢，页面加载要等好几秒，刷新一下订单列表卡得像老式录像机？查了一圈才发现，问题出在MySQL上。其实很多性能瓶颈并不是服务器不够强，而是数据库没调好。只要动动手，改几个配置，优化几条SQL，效果立竿见影。
先看慢查询日志，找到“拖后腿”的SQL
MySQL自带的慢查询日志是排查性能问题的第一步。打开它，让系统记录执行时间超过设定阈值的语句。比如设置超过1秒就算“慢”：
slow_query_log = ON
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow.log重启MySQL后，用mysqldumpslow或pt-query-digest分析日志，就能发现哪些SQL最耗时。常见问题包括全表扫描、缺少索引、重复查询等。
给字段加索引，但别乱加
索引就像书的目录，能快速定位数据。但不是所有字段都适合加索引。比如用户表按手机号登录，那就给phone字段加索引：
ALTER TABLE users ADD INDEX idx_phone (phone);但如果你给“性别”这种只有男/女两个值的字段加索引，几乎没用——因为数据太集中，MySQL还是得扫一大片。更糟的是，索引越多，写入越慢，因为每次插入都要更新索引树。
避免SELECT *
很多人写SQL图省事，直接SELECT *。可你真需要所有字段吗？特别是表里有TEXT大字段时，查出来又不用，白白浪费IO和内存。明确列出要用的字段，比如：
SELECT id, name, email FROM users WHERE status = 1;这样不仅快，还能减少网络传输量。
合理使用分页，别让LIMIT骗了你
翻到第100页的数据，写成LIMIT 10000, 20看起来没问题，但MySQL得先跳过前10000条。数据量一大，这句就变成慢查询。更好的办法是用主键范围查询：
SELECT id, title FROM articles WHERE id > 10000 ORDER BY id LIMIT 20;配合前端记住上一页最后一个ID，效率高得多。
调整关键配置参数
默认配置适合入门，但生产环境得调。比如innodb_buffer_pool_size，它决定多少数据能缓存在内存里。如果服务器有8G内存，可以设为5-6G：
innodb_buffer_pool_size = 6G再比如max_connections，默认151可能不够用。如果应用连接池设了200，这里就得同步调高，否则会报“Too many connections”。
定期做表结构优化
用OPTIMIZE TABLE可以整理碎片，尤其对频繁删除、更新的大表有用。比如订单历史表每月归档一次后，顺手优化一下：
OPTIMIZE TABLE order_history_202403;不过这操作会锁表，最好在低峰期执行。
调优不是一锤子买卖，而是一个持续观察、测试、调整的过程。上线新功能前，不妨先在测试库跑一遍慢查询分析。把数据库当成一个需要日常照料的服务，而不是丢进去就不管的黑盒子，你会发现系统稳定多了。