干了十几年数据库运维，我得说，这活儿看着像技术活，其实更像伺候一位脾气古怪的祖宗。你刚觉得它稳如老狗，它就能在某天凌晨三点给你整出个连接池爆满，让你从被窝里爬起来排雷。今天这篇东西，就是把我这些年踩过的坑、摔过的跤，还有那些真正管用的招儿，掰开了揉碎了跟你聊聊。别指望看完了就能成大师，但至少下次数据库出问题，你能少走几步弯路。
先说性能优化这事儿，很多人一上来就调参数、改配置，恨不得把内存翻一倍。其实最该看的，是慢查询日志。我见过太多运维兄弟，每天盯着CPU、内存曲线看，机器跑得比风扇还快，结果业务方抱怨页面卡成PPT。打开慢查询一查，好家伙，一个没索引的JOIN查询，跑了十几秒，把整个库拖下水。优化第一原则：先看SQL，再看系统。索引没建对，你给数据库加再多CPU也是白搭。有个小技巧，用把慢日志分析一下，重点关注那些“执行次数多且时间长”的查询，这才是真凶。别被那些“执行一次但巨慢”的查询骗了，它们虽然扎眼，但不常出现，优先级得往后排。
再聊聊索引设计，这玩意儿看起来简单，但坑特别深。最常见的问题是“索引滥用”——为了查询快，恨不得给每个字段都加索引。结果呢？写入性能直线下降，因为每次INSERT、UPDATE都得同步更新索引树。我见过一个案例，某电商库的订单表，加了十几个索引，结果双十一大促期间，写入延迟飙到正常值的五倍。解决办法：用和反复验证，删掉那些从没被用过的冗余索引。另外，联合索引的字段顺序要按选择性排，选择性高的放前面。比如用户ID和订单状态，用户ID唯一性高，就放前面；状态只有几个值，放后面。
说完索引，不得不提连接池这关。很多运维新手觉得连接池越大越好，恨不得给数据库开个几百个线程。但现实是，数据库的连接数有上限，而且每个连接都消耗内存和CPU上下文切换的开销。我见过某公司用默认的100个连接跑业务，结果高峰期连接全占满，新请求排队等超时。优化思路：根据业务并发量算一下，连接池大小 = (CPU核心数 * 2) + 有效磁盘数。如果业务里有大量长连接或慢查询，还得再减。另外，用定期检查那些“Sleeping”状态的连接，超过一定时间就杀掉，别让它们占着茅坑不拉屎。
故障排查这块，最怕的是“玄学问题”——比如磁盘空间突然满了，但查了一圈，数据文件没膨胀，日志也没爆。我遇到过两次，一次是MySQL的binlog没清理，积累了几百G；另一次是慢查询临时文件写满了tmpdir。排查第一步：先用看哪个分区满了，然后用逐层往下查，找到那个“吃空间”的家伙。如果是binlog，设置为7天；如果是临时文件，检查SQL优化，或者把tmpdir挪到独立分区。别猜，别拍脑袋，用数据说话。
还有一个高频故障，就是主从复制延迟。你刚把主库的写操作跑完，从库却迟迟不更新，结果业务读到旧数据，闹出大乱子。常见原因：主库的写入压力太大，或者从库的硬件配置太低，或者网络带宽不够。排查时，用看这个值，如果持续增长，先检查从库的CPU、IO是否被其他查询占满。如果从库配置没问题，那可能是主库的binlog格式设置成了ROW，导致从库需要逐行应用变更，性能下降。解决办法：把主库的改成MIXED，或者把从库的设成2-4，开启并行复制。
说到这儿，你可能会觉得“这些我都懂”，但真正出问题的时候，最缺的其实是冷静的排查顺序。我给自己定了个铁律：先看业务日志，再看数据库日志，最后动配置。有一次，同事半夜打电话说数据库挂了，我远程上去一看，业务日志里全是“连接超时”，数据库日志里却干干净净。我差点就要重启数据库了，但多留了个心眼，查了下网络设备，结果发现是防火墙把数据库端口给封了。要是直接重启，问题没解决，还白耽误半小时。
最后我想说，数据库运维这行，永远没有“完美”的状态。你今天优化完一个慢查询，明天可能有个新的业务模型冒出来；你刚调好连接池参数，流量峰值又翻了一倍。真正牛逼的运维，不是能把所有问题都提前堵住，而是每次出故障后，能快速定位、干净利落地解决，并且把经验变成脚本或工具，让下一次少踩坑。比如，把常见的故障排查步骤写成自动化脚本，或者搭建个慢查询监控告警，让问题在萌芽阶段就被发现。别指望一劳永逸，但可以追求每一次都比上次更快、更稳。
