MySQL数据库服务器性能优化这事儿，说起来挺玄乎，其实拆开了揉碎了，就是那几件事。很多新手DBA上来就堆硬件，SSD换NVMe，内存加到128G，结果查询还是慢得像蜗牛爬。问题出在哪？根子上还是没搞明白MySQL到底在干啥。你给它一坨配置参数，它就像个听话的机器人，你设错了，它就跑偏了。比如innodbbufferpoolsize，这玩意儿决定了内存能缓存多少数据和索引，设小了，磁盘I/O嗷嗷叫；设大了，内存不够用，系统直接OOM。我见过一个案例，一台16G内存的服务器，buffer pool设了12G，结果查询一多，MySQL自己就崩了。所以第一步，先得把硬件和配置参数对上线，别光看数字大就觉得好。
说到配置，最坑人的就是那些“默认设置”。MySQL安装完，很多参数都是保守的，比如maxconnections默认151，听起来够用吧？但你要是跑个高并发的Web应用，几百个连接一上来，每个连接都占着内存和CPU，系统直接卡死。还有querycachesize，这玩意儿在MySQL 8.0已经废了，但很多人还在用老版本，设了个256M，结果查询缓存命中率不到10%，反而因为锁竞争拖慢速度。真正的优化思路是：先摸清业务场景。写多读少？读多写少？数据量多大？并发多高？比如电商秒杀系统，写操作爆炸，那就得调高innodblogfilesize，减少日志刷盘频率；如果是新闻网站，读操作占99%，那就把readrndbuffersize和sortbuffersize设大点，让排序和随机读更顺畅。别抄网上的“万能配置”，那是给幽灵服务器用的。
配置搞定了，接下来是索引优化，这才是实战里的硬骨头。很多人觉得索引就是建个B+树，简单。但实际上一堆坑等着你。最典型的是联合索引，比如你建了(a,b,c)的索引，结果查询条件里只用了a和c，跳过了b，那索引就只用到a，c那部分还得全表扫描。还有隐式类型转换，字段是字符串，你传了个数字进去，MySQL就把索引字段转成数字，索引直接废了。我处理过一个慢查询，一个表200万条记录，查询花了8秒，explain一看，type是ALL，全表扫描。原因就是where条件里用了函数，比如WHERE DATE(createtime) = '2024-01-01'，索引根本用不上。改成createtime >= '2024-01-01' AND createtime < '2024-01-02'，查询瞬间变0.01秒。别小看这些细节，索引优化做得好的，性能提升十倍起步。
索引只是基础，查询语句本身的写法才是真正的分水岭。很多程序员写SQL就像写散文，随心所欲。比如SELECT *，把整张表所有字段都捞出来，网络传输和内存占用直接爆炸。更离谱的是，有人在JOIN的时候，关联字段没有索引，或者用了LEFT JOIN，结果右边表没匹配到数据，MySQL硬着头皮全表扫描。还有子查询的滥用，比如IN (SELECT ...)，MySQL8.0之前优化得很差，会把子查询结果物化成临时表，再逐行匹配，性能烂到家。我见过最夸张的一个案例，一个电商后台的报表查询，跑了半小时没出来，DBA一看，SQL里套了四层子查询，每层还用了ORDER BY和LIMIT，临时表堆成山。改成JOIN加分组聚合，5秒搞定了。所以写SQL的时候，心里得装着MySQL的执行计划，想想它会怎么走索引，怎么关联表，别让数据库替你“思考”。
说到实战，慢查询日志是绕不开的工具。很多公司上线了系统，从不看慢查询日志，结果用户投诉了才去排查。其实配置好longquerytime参数，比如设成1秒，然后定期分析慢查询日志，用pt-query-digest这类工具汇总，就能发现性能瓶颈。比如某个查询频繁出现，执行时间稳定在1.5秒，那就要看是不是索引没命中，或者数据分布不均匀。还有一点，慢查询日志本身也有性能开销，别在生产库上长期开着，建议周期性抓取，比如每天凌晨低峰期开一小时，收集完就关。我有个朋友，公司业务增长快，数据库越来越慢，开了慢查询日志后，发现80%的慢查询都来自一个没加索引的联表查询，加了索引后，整个系统响应时间从3秒降到0.2秒。你看，有时候问题就这么简单，但你不去看，它就永远在那。
优化到这一步，很多人觉得差不多了，但还有一个隐藏的杀手：锁竞争。MySQL的InnoDB引擎虽然支持行级锁，但如果你的事务没处理好，照样会引发锁等待。比如一个UPDATE语句，没走索引，就会锁全表，其他事务全堵死。还有间隙锁，在可重复读隔离级别下，InnoDB会锁住一个范围，防止幻读，但如果范围太大，比如WHERE id > 1000，那1000以后的所有行都被锁了，并发直接崩。我处理过一个电商订单系统，高峰期订单创建失败，日志里全是lock wait timeout。排查后发现，有个长事务在做批量更新，锁住了整张订单表，其他事务等30秒就超时了。解决方案很简单：把大事务拆成小批次，每个批次更新100条，并且给WHERE条件加上精确索引，锁的范围就小了。另外，隔离级别也可以考虑降级，比如用读已提交，减少间隙锁，但得确认业务上能接受。
别忘了定期维护。MySQL不是一次性优化完就一劳永逸的。数据会增长，索引会碎片化，统计信息会过时。比如一张表频繁增删改，索引页会变得不连续，查询时得读更多磁盘块，性能就下来了。定期用OPTIMIZE TABLE或者重建索引，能整理碎片，但要注意，这个操作会锁表，得挑业务低峰期做。还有，统计信息自动更新默认是变化的10%左右，但如果数据增长快，统计信息滞后，优化器就可能选错执行计划。可以手动设置innodbstatsautorecalc = 1，或者定期执行ANALYZE TABLE。我见过一个案例，一张表每天新增100万条记录，统计信息一周没更新，结果优化器选了一个全表扫描，查询从0.1秒变成10秒。所以，性能优化不是一次性的，它是个持续的过程，你得像养宠物一样，定期喂它、溜它、检查它的健康状况。从配置到实战，每一步都得踩实了，MySQL才能给你跑出好成绩。
