某电商平台双十一期间因索引碎片率飙升导致核心订单查询超时长达7秒，最终损失近百万单转化——这是数据库管理员最怕遇到，却又最常见的场景之一。在长期一线运维中，有三个问题被反复问起，它们不是教科书上的理论，而是每天都会卡住DBA的实战痛点。

为什么SQL跑得慢，但服务器资源明明很空闲？

某物流公司的仓储系统每天处理50万笔入库单，数据库服务器CPU长期低于20%，内存空闲60%，但一条简单的按订单号查询却频繁超时。问题出在表设计上：他们把订单状态、物流轨迹、退款记录全部塞进一张超过2亿行的单表，并用一个text字段存储JSON格式的轨迹数据。每次查询即使只取一条记录，也需要扫描全表以解析text字段。将轨迹数据拆成分表、为订单号建立覆盖索引后，同一查询从4.2秒降至3毫秒。资源空闲不等于查询高效，瓶颈往往在数据结构的笨重设计上，而非硬件算力。

备份文件完整，为何恢复时总是差数据？

某金融科技公司每夜做全量备份，备份日志显示成功，文件大小正常。但当季度审计需要还原一个月前的数据库时，发现某个关键账户表缺失了三天内的交易流水。调查发现，备份脚本写死了“备份所有数据库”，但运维人员在上个月新增了一个归档库用于存放历史分区表，而新库的备份策略并未自动继承。更隐蔽的是，某张表使用了在线DDL变更（如MySQL的pt-online-schema-change），在备份窗口内发生结构变动，导致备份数据不一致。恢复失败最常见的原因不是备份文件损坏，而是备份范围定义遗漏、变更管理失控，以及缺乏定期的恢复演练。

主从复制延迟，除了换硬件还能怎么办？

某社交平台用户发布动态后，好友刷新推荐流经常看不到新内容，但数据库监控显示主库负载正常。问题根源在从库：主库每秒钟写入1.2万条用户行为事件，从库单线程的SQL线程需要逐条重放这些写操作。当某张热门内容表在主库执行大批量更新（如修正所有用户标签）时，从库的复制延迟会飙升至15秒以上。核心解法是：将大事务拆分成每1000条一批的小事务执行，同时为从库开启并行复制，并把非关键统计查询（如点赞数汇总）路由到专门的只读副本，而非唯一的从库。延迟的根因通常不是网络或磁盘，而是单线程重放的设计瓶颈和事务粒度失控。

如果你正在管理生产数据库，请避开以下三个高频误区：

• 误区一：用监控告警代替主动巡检。 每天花10分钟查看慢查询日志和索引碎片率，比等到告警响了再排查更省时间。建议每周运行一次索引使用统计，清除长期未被使用的冗余索引。
• 误区二：备份只看成功状态不看恢复结果。 每月至少做一次全流程恢复演练，把备份文件恢复到临时环境并校验数据行数、最新时间戳和关键表的聚合值。
• 误区三：把主从复制当成高可用方案。 复制延迟、网络分区、半同步超时都可能导致数据不一致。真正的生产高可用必须搭配自动故障切换（如MHA或Orchestrator）和定期的数据一致性校验。