某中型电商公司因一次数据库连接池耗尽事故，导致核心交易系统中断 47 分钟，损失预估超 200 万元，而根源仅仅是连接池最大连接数设成了默认值的 50%。这类数据库管理问题并非孤例，许多团队直到故障爆发才意识到配置、监控或设计上的致命疏漏。

连接池耗尽：不是“不够用”，而是“不会回收”

很多开发者以为连接池耗尽就是并发太大，实际上更常见的死因是连接泄漏。某 SaaS 平台日志显示，高峰时段活跃连接数稳定在 80 左右，但池内总连接数却飙升至 500 并触发熔断。排查发现，一个批量导入接口在异常分支中漏掉了关闭连接的 try-finally 块，让连接池里的连接只增加不释放。具体场景中，建议通过监控工具（如 pmm、datadog）观察连接活跃曲线：如果总连接数持续上升而活跃连接数平稳，大概率就是泄漏。排查时可临时调小连接超时（如 wait_timeout 设为 30 秒），让泄漏连接快速被驱逐，同时逐段注释业务代码定位漏洞。

索引失效：最隐蔽的慢查询陷阱

某内容平台一条慢查询耗时从 0.5 秒突然飙到 12 秒，开发团队反复优化 sql 结构都无效。最终发现是因为字段类型不匹配：查询条件中传入的是字符串 '12345'，但表中对应列是整数类型，MySQL 自动对每一行做了隐式类型转换，导致全表扫描。另一个典型场景是联合索引中字段顺序与查询条件不匹配：索引是 (a,b,c)，但 where 条件只写 b 和 c，索引完全用不上。建议每次建索引后，先用 explain 检查 key_len 和 extra 字段：如果 extra 出现 “using where; using filesort” 且 key_len 比预期短，说明索引没被充分利用。对于已有线上系统，定期用 pt-query-digest 抓取慢查询日志，按平均耗时降序排，重点处理前 20% 的查询。

备份恢复：90% 的团队只测了“备份”，没测“恢复”

某金融公司每天凌晨全量备份，持续两年无事故。直到一次机房断电后，运维发现备份文件在异地存储中损坏了最后 2MB 的校验块，导致整份备份无法还原。更常见的情况是：备份脚本只验证了文件大小非零，却从未真正跑过一次恢复演练。具体场景中，建议每季度做一次“沙箱恢复”：在隔离环境中用备份文件还原一个完整数据库，然后运行几条关键查询（如统计昨日交易总额、拉取最新 100 条用户注册记录）来验证数据完整性。另一个容易被忽略的点：binlog 的保留天数设置。如果只保留 7 天，而恢复需要用到 8 天前的 binlog 来补增量，恢复就注定失败。建议将 binlog 保留期设为全量备份间隔的 2 倍以上，并额外存储一份到离线介质。

最后给出三条最常踩的误区：第一，不要只相信默认配置，数据库安装后的第一件事是检查连接池、缓冲区、日志保留期，并根据业务峰值做压力测试调整；第二，不要等到慢查询出现才建索引，建表时就该根据最频繁的 where 和 order by 字段提前设计联合索引，宁可多建一个无用索引（后期删除）也别让线上全表扫描；第三，不要用“备份成功”四个字衡量备份质量，真正的检验标准是“恢复后数据零丢失、查询零异常”，每半年至少做一次完整恢复演练并记录耗时。