SQL数据库扩容需先识别瓶颈、预测增长、定位问题，再选择优化、垂直或水平路径，并预留弹性与验证机制。
SQL数据库扩容不是简单加内存或换硬盘，而是要先看清当前瓶颈在哪、数据增长有多快、业务对响应时间有多敏感。盲目扩容可能花了不少钱，性能却没提升，甚至引发新问题。
看懂容量增长趋势：别只盯当前大小
数据库容量不只是“现在占了多少GB”，关键是要预测未来6–12个月的增长节奏。比如用户表每月新增50万行，每行平均2KB，一年就多12GB；日志表若没归档策略，可能每月暴涨30GB。建议用以下方式量化：
- 按表/按库统计近3个月的每日数据增量（可通过information_schema.TABLES + 定期快照对比）
- 识别“膨胀大户”：大文本字段（TEXT）、频繁更新的计数器、未清理的历史流水
- 检查索引占比——有些库索引体积已超数据本身，说明设计或查询模式有问题，扩容前该先优化
定位真实性能瓶颈：CPU、IO、锁还是查询？
慢≠要扩容。很多“卡顿”其实和容量无关，而是执行计划退化、缺失索引、长事务阻塞导致。先跑几条关键诊断语句：
- 查等待事件：MySQL用red">SHOW ENGINE INNODB STATUS看lock wait、log waits；PostgreSQL查pg_stat_activity和pg_stat_bgwriter
- 抓TOP SQL：开启慢查询日志（long_query_time ≤ 1s），用pt-query-digest分析耗时分布
- 看资源水位：CPU持续＞80%？磁盘IO await > 20ms？连接数接近max_connections？每项指向不同扩容方向
选对扩容路径：垂直、水平还是架构调整？
不是所有场景都适合分库分表。优先级建议是：
- 先优化再扩容：加覆盖索引、改批量写入为异步落库、清理冷数据、升级到更高压缩比的存储引擎（如InnoDB Page Compression）
- 垂直扩容见效快：适用于单实例还能扛住，只是资源吃紧——升配CPU/内存、换NVMe盘、调优buffer pool / shared_buffers
- 水平拆分要谨慎：仅当单机已达硬件极限+业务可接受路由复杂度时考虑；优先从读多写少模块切出（如订单详情→订单主表分离）
预留弹性与验证机制：扩容不是一锤子买卖
上线后必须验证是否真解决问题。建议每次扩容后做三件事：
- 压测对比：用相同数据量+真实流量回放，对比QPS、P99延迟、错误率
- 设置监控基线：扩容前后的磁盘使用率增速、慢查数量趋势、连接池排队时长
- 留10%–20%余量：避免刚扩容完就触发告警；同时制定下一次评估节点（比如容量达70%或慢查周增＞15%时自动触发复盘）
