数据库备份占用了60%以上的存储空间，却仍有75%的企业在恢复测试时才发现备份文件损坏——这是《2024年数据库运维报告》里的真实数据。

备份策略选全量还是增量？先看恢复时间目标

某电商平台曾采用每日全量备份，单次备份耗时4小时，但突发宕机后恢复数据仍需12小时。这不是备份频率的问题，而是策略错配。全量备份适合数据量小于500GB的场景，一旦超过1TB，建议采用“周全量+日增量+小时日志”组合。比如一家金融公司把全量周期从每天改为每周日，周一到周六只做增量备份，存储成本下降40%，恢复时只需先加载最近一次全量，再按时间顺序应用增量日志，整体恢复时间压缩到2小时内。

慢查询优化不是加索引，而是先排查全表扫描

开发团队经常遇到“加了索引还是慢”的困境。举个具体例子：一张用户订单表有50万行，按订单日期字段加了B+树索引，但查询“WHERE order_date > '2024-01-01' AND status = 'pending'”依然执行3秒以上。问题出在status字段没有索引，数据库先通过order_date索引过滤出30万行，再对这30万行做全表扫描匹配status条件。正确的做法是把两个条件组合成复合索引(order_date, status)，查询直接走索引覆盖扫描，耗时降到0.2秒。记住一个原则：索引列的顺序应匹配查询条件的筛选力度，把区分度高的列放前面。

连接池大小到底设多少？不是越大越好

某SaaS平台把连接池从20提高到100，结果数据库响应时间反而从2ms飙升到50ms。原因是操作系统调度线程的开销随着连接数指数增长，同时数据库内部锁竞争加剧。业界常用公式是“连接数=核心数×2+机械盘数量”，但更实用的做法是压测：从10个连接开始，每次增加5个，监控TPS（每秒事务数）的拐点。比如在16核服务器上，测试发现连接数超过35后TPS曲线下降，最终稳定在30连接是最优值。大连接池只会制造伪并发，真正的并发优化在减少事务时长。

日常最常踩的三个误区

• 误区一：定期备份就万事大吉——至少每季度做一次完整恢复演练，把备份文件还原到测试库并运行业务核心查询，验证数据完整性。去年有家物流公司发现三个月前的备份文件因磁盘坏道无法读取，幸亏有月备份才避免灾难。
• 误区二：所有表都必须加索引——写入频繁的表（如日志表）每增加一个索引，写入性能下降约10%。只给查询频率高于写入频率2倍以上的字段加索引，其余用读写分离解决。
• 误区三：异常日志只要不报错就不用看——数据库错误日志里“lock wait timeout”出现一次可能是偶然，但每小时出现10次就说明存在死锁。用监控工具对死锁频率做告警阀值（比如每分钟超过5次），比等用户投诉再排查有效得多。