数据库运维这事儿，干过的都懂，MySQL看着简单，真出问题能让人一夜白头。我干了十几年运维，踩过的坑能绕西湖三圈。今天就跟大伙儿聊聊MySQL性能调优和故障排查，都是实战里摔出来的经验。别指望一口气学会所有，但至少下次数据库报警时，你能知道先去哪儿看看，而不是干瞪着监控屏幕发呆。
先说排查故障的第一原则：别急着翻配置文档。很多新手一遇到慢查询就怀疑参数没调好，其实八成问题出在SQL语句上。我见过最离谱的一次，某电商平台促销期间数据库CPU飙到99%，查了半天发现是运营人员写了个全表扫描的报表查询，一跑就是十分钟。MySQL的慢查询日志是救命稻草，开启后把超过1秒的语句都记下来，配合pt-query-digest工具分析，基本能定位到病根。记住，调优前先做基线，记录正常状态下的QPS、连接数、磁盘IO，否则你都不知道调完是变好了还是更糟了。
索引优化是性能调优的核心，但很多人用错了。不是每个字段都加索引就完事，联合索引要遵循最左前缀原则。比如你建了(a,b,c)的联合索引，查询条件只用到b和c，索引根本不会生效。我调过最典型的一个案例：某财务系统有个表每天写入200万条记录，查询却只查最近一周的数据。原先是按时间字段建了普通索引，但数据量一大就卡死。后来改成按日期分区表，配合覆盖索引，查询时间从30秒降到0.1秒。索引不是越多越好，写入频繁的表索引多了反而拖慢插入速度。运维人员要经常用explain看执行计划，确认SQL是否真的走了索引。
连接池配置是个容易被忽略的坑。很多开发图省事，连接池最大连接数设成1000，觉得越多越好。实际上MySQL默认最大连接数是151，你设1000也没用，而且连接数一多，上下文切换的开销能把CPU拖垮。我处理过一个支付系统故障，业务高峰期连接数突然飙升到300，数据库直接拒绝连接。排查发现是应用层有个连接泄露的bug，连接用完没释放。解决方案是限流：业务层连接池设成50到100，数据库端设置waittimeout和interactivetimeout到30秒，超时连接自动断开。同时用show processlist定期检查睡眠连接，超过阈值的直接kill掉。
磁盘IO瓶颈往往是隐形的杀手。很多人只盯着CPU和内存，忘了数据库最终数据要落盘。有个真实案例：某日志系统每天写入500GB数据，用了半年后突然变慢，查询都要几十秒。查了半天发现磁盘是传统机械硬盘，随机读写性能早就到了极限。解决方案是把binlog和数据文件分开存放，用SSD做数据盘。另外，innodbflushlogattrxcommit这个参数很关键：设成1最安全但最慢，每次事务提交都刷盘；设成2性能好但可能丢失1秒数据。金融系统必须用1，非核心业务可以设成2，要自己权衡。
事务和锁的问题是最容易引发线上故障的。有次电商大促，突然所有下单接口都报超时，数据库连接池占满。查了慢日志发现一条更新库存的SQL一直在等待行锁。原来有个后台事务开了没提交，锁住了某款爆款商品的所有库存行。解决方案很简单：给所有事务设置超时时间，innodblockwaittimeout设成30秒，超过就自动回滚。同时业务层要加重试机制，锁冲突自动重试三次。更重要的，开发规范里必须要求事务操作时间不能超过5秒，避免长事务拖死数据库。
说到故障排查，内存和缓存配置也容易翻车。MySQL的innodbbufferpoolsize理论上设成物理内存的70%左右，但很多人直接照搬公式。我见过一台机器上同时跑着MySQL、Redis和Java应用，buffer pool占了16G内存，结果Java应用频繁Full GC。后来降到10G，问题解决了。另外，buffer pool的命中率要监控，低于95%说明内存不够或索引不合理。用show engine innodb status查看命中率，结合informationschema里的表数据量分析。还有个常见误区：tmptablesize设得太大，导致查询临时表直接写到磁盘，性能暴跌。建议设成16M到32M，配合maxheaptable_size使用。
备份和恢复策略是运维的一道防线。很多人觉得有主从同步就万事大吉，结果误删数据时才发现从库也同步删了。我的做法是：每天凌晨全量备份，每半小时增量备份，保留最近30天的备份文件。用xtrabackup做物理备份，mysqldump做逻辑备份。但更关键的是要定期演练恢复流程，我每个月都会在测试环境模拟一次数据丢失，从备份恢复到一致性检查，整个过程控制在2小时内。别等到真的出事了才发现备份文件损坏或者恢复流程有坑。
总结一下，MySQL运维没什么玄学，就是扎扎实实做好监控、分析、预案。监控要覆盖慢查询、连接数、磁盘IO、buffer pool命中率这几个核心指标；分析要习惯看explain和执行计划；预案要做到故障发生时能快速定位、快速恢复。送大家一句话：数据库出问题不可怕，可怕的是不知道为什么出问题。多复盘、多总结，把每次故障都变成经验，你的MySQL就能越跑越稳。
