许多资深后端工程师在数据库调优半年后，发现索引命中率从95%掉到60%，不是因为慢查询变多了，而是业务增长导致数据分布倾斜，旧索引策略完全失效。这是最容易被忽视的“隐性性能杀手”。

为什么你的数据迁移总在凌晨通知“索引重建失败”？

典型场景：某电商平台每月大促后执行数据归档，将半年以上的订单从热库迁移到冷库。迁移脚本通常先删除旧表索引、批量插入数据、再重建索引。但一旦冷库磁盘IO达到瓶颈，重建索引时锁表时间过长，导致在线业务连接池爆满。根源在于MySQL在重建主键索引时，会扫描整个表并阻塞所有写操作。更稳妥的做法是：先在冷库中按相同结构创建空表并建好索引，然后用INSERT INTO ... SELECT ...分批迁移，每批控制行数（如10万行），并暂停几秒给磁盘喘气。

慢查询日志里最常见的“隐式转换”陷阱，如何一条SQL就干掉索引？

一个真实案例：某SaaS公司的用户表里，user_id字段是字符串类型，但开发在接口层误传了整型。SQL写成了WHERE user_id = 123456，而不是WHERE user_id = '123456'。MySQL对字符串列和整数比较时，会自动将字符串列全部转换为整数，这意味着字段上的索引根本不会生效，会触发全表扫描。更隐蔽的是，user_id值如果包含前导零（如“00123”），转换后变成123，结果完全错误。排查方法是打开explain extended查看warning，它会明确提示“隐式转换导致索引失效”。

PostgreSQL 的 VACUUM 为什么越跑越慢，甚至撑爆磁盘？

一个被忽略的细节：当表中有大量死元组时，VACUUM 会先标记可回收空间，但不会自动归还给操作系统。假设你频繁更新某张表的记录，每次更新都产生死元组，VACUUM 清理后表文件大小可能不降反升，因为 PostgreSQL 内部的空闲空间映射（FSM）结构退化，导致后续的新插入数据无法使用已回收的空间。更糟的是，如果开启了 autovacuum 但阈值设置过低，VACUUM 进程会频繁触发，消耗大量CPU和IO。解决方法是：定期执行 VACUUM FULL 或 CLUSTER 来重写表，但注意这需要排他锁，最好在维护窗口操作；或者调大 autovacuum_vacuum_scale_factor 参数，降低扫描频率。

• 误区一：索引建得越多越好。 每个索引都会拖慢写入速度，定期用 pt-index-usage 或 pg_stat_user_indexes 扫描那些零扫描的冗余索引，果断删除。
• 误区二：备份只做全量不测恢复。 至少每季度做一次灾难恢复演练，包括验证备份文件一致性、模拟数据损坏后的还原步骤，确保恢复时间RTO在业务容忍范围内。
• 误区三：新版本数据库直接升级不测试。 尤其是MySQL 5.7 到 8.0，默认字符集从latin1换到utf8mb4，会导致索引长度限制变化；PostgreSQL 14到15，分区表的分区调度行为有调整。先在新版环境下跑一遍所有CRUD核心用例。