一个中型电商数据库在促销活动期间每秒会涌入近万次写入请求，如果运维团队还在用传统“撞锁—重试”处理并发，响应延迟会从 2 毫秒飙到 200 毫秒，用户直接看到白屏。

并发写入冲突：别再用业务层“撞锁”，改用 MVCC + 应用层队列

很多团队遇到高并发写入时，第一反应是给每条 SQL 加悲观锁。但数据库行锁在极端并发下会退化为表锁，比如某票务系统在开票瞬间，同个商品 ID 的更新请求挤爆锁队列，TPS 从 3000 降到 300。正确的做法是依赖数据库自身的 MVCC（多版本并发控制）机制，比如 PostgreSQL 或 MySQL InnoDB 的快照读，再在应用层通过内存队列（如 Redis 列表）将同一商品的写操作串行化。一个实际案例：某游戏排行榜服务将玩家积分更新写入 10 个分片键对应的队列，数据库侧再无锁冲突，写入吞吐提升了 8 倍。

慢查询优化：最有效的不是建索引，而是改 SQL 写法

很多 DBA 拿到慢查询日志第一件事就是加索引，但忽略了一个常见场景：SELECT * FROM orders WHERE status = 'shipped' ORDER BY created_at DESC LIMIT 10。即使给 status 和 created_at 建了联合索引，如果 shipped 状态的行占全表的 60%，MySQL 依然会扫描 60% 的数据再排序。更实用的办法是——把条件改为 status IN ('shipped', 'delivered') 或使用覆盖索引：SELECT id, status, created_at FROM orders ...。某物流系统将这类查询改完后，98% 的慢查询小时从 20 秒降到 30 毫秒，而索引只多花了 2MB 空间。

备份与恢复：增量备份不是万能药，全量快照才是保命符

某公司每周做一次全量备份、每天做增量备份，结果周三磁盘故障后，运维发现周二增量备份文件损坏，只能恢复到周一的全量快照，丢失了 48 小时数据。增量备份依赖连续日志链，任何一个节点损坏都会导致恢复失败。正确的策略是：每天凌晨做一次物理全量快照（比如 XtraBackup 或 pg_basebackup），保留最近 7 天的全量副本；同时将 binlog 或 WAL 归档到异机对象存储。某金融机构用这个方案后，恢复点目标（RPO）控制在 5 分钟以内，恢复时间目标（RTO）不超过 1 小时。

• 误区一：认为索引能解决所有慢查询——多表 JOIN 或 ORDER BY 大字段时，索引段扩展反而会拖慢写入，先分析执行计划再动手。
• 误区二：备份只要做一次就安全——必须定期演练恢复流程，至少每月用测试库还原一次全量备份并验证数据完整性。
• 建议三：高并发场景下，把“每次写操作都带事务”改为“批量提交+异步补偿”——比如每 100 条记录提交一次事务，能减少事务日志刷盘次数，提升 3-5 倍写入速度。