数据库迁移后性能骤降 50% 的案例中，超过 70% 是因为索引策略没跟着数据量增长调整。这是 DBA 社区 2024 年第三季度统计的真实数据，也是《数据库管理最热问答集锦，看完不再困惑》里被追问最多次的场景。

为什么加了索引反而让查询变慢

某电商平台在订单表上给“用户ID”和“下单时间”各建了一个独立索引，结果双十一期间写入延迟暴增 300%。根源在于多列独立索引导致优化器选错执行计划，实际走了全表扫描。正确的做法是建联合索引，把过滤度高的“用户ID”放前面，“下单时间”放后面。测试表明，同样 500 万行数据，联合索引比两个独立索引快 8 倍，写入开销还降低 40%。

连接池改大就能解决并发瓶颈吗

一家 SaaS 公司把连接池从 50 调到 200 后，数据库 CPU 直接飙到 95%，请求反而超时更频繁。这是因为 PostgreSQL 每个活跃连接都要消耗约 10MB 内存和独立 CPU 上下文，连接数翻倍意味着上下文切换次数翻 4 倍。实际优化应该监控“等待事件的分布”，如果大部分时间花在“CPU 等待”而不是“IO 等待”，说明连接数已经溢出了运维临界点。

慢查询日志里最常见的认知偏差

某金融系统每天产生 2000 条慢查询日志，DBA 按执行时间排序优化了前 10 条，但数据库负载没降。拆解后发现，执行次数最频繁的是一条“SELECT COUNT(*)”语句，占全部查询的 60%，虽然单次只慢 0.5 秒，但累计消耗了 300 秒的 CPU 时间。正确的优先顺序应该是按“执行次数 × 平均耗时”排序，而不是只看单次耗时。这条规则能帮团队在两周内把整体查询延迟降低 75%。

• 误区一：只关注查询时间，不关注 IO 次数。 把一条查询从 2 秒优化到 0.1 秒，但如果它每秒执行 100 次，磁盘 IO 仍然会打满。优先用缓存层（如 Redis）减少重复读取。
• 误区二：遇到死锁就加锁超时参数。 单纯把 innodb_lock_wait_timeout 从 50 秒改到 10 秒只是掩盖问题。应该用 SHOW ENGINE INNODB STATUS 分析死锁链路，调整事务顺序或改用乐观锁。
• 误区三：备份后不做恢复演练。 某公司每周全量备份，但恢复时才发现磁盘空间不够、备份文件损坏。每月至少做一次“从备份到对外服务”的全流程演练，并记录恢复耗时。