晚班分拣高峰数据库告急，扩容窗口只剩两小时，正确顺序永远是：先降载、再热扩，最后才碰参数。 顺序反了，数据库可能连最后两小时都撑不住。
晚班分拣系统的数据负载,像一列满载的火车突然冲进隧道，订单量在晚上六点到十点之间集中爆发，数据库的活跃会话数跟着往上蹿，这时候你盯着CPU看，常常以为算力不够，实际卡住分拣线的，是连接池被慢查询占满，锁资源互相掐架，分拣线每停一分钟，后面的包裹就会堆成山。
晚班分拣高峰数据库扩容方案：两小时窗口先降载再扩容
扩容窗口是晚班高峰期里面偷出来的两小时,通常来自系统自动告警到人工介入的那段时间，真正的高手不会一上来就敲ALTER TABLE，更不会直接重启数据库，而是先把负载压下去，腾出手来做原地热扩。
分拣系统数据库告警怎么办？先判断是“忙晕”还是“病倒”
登录数据库,执行一句命令就能看出端倪：
SHOW PROCESSLIST;
如果看到大量会话卡在Sending data、Sorting result、Copy to tmp table这些状态，说明分拣系统不是硬件病倒了，而是某些SQL把道路堵死了，晚班分拣场景里，相当一部分告警来自后台报表任务和慢查询，它们和分拣主流程抢连接，把业务查询活活憋死。
这时候不要急着扩容,先动手清掉不听话的会话：
- 找到占用CPU最高、执行时间最长的会话ID
- 执行
KILL <thread_id>;，一次杀掉排队最久的几个 - 通知应用侧,把非核心的统计查询全部切到只读副本，或者直接停掉
这一套动作做完,数据库的活跃会话数往往会明显回落，很多情况下根本不需要扩容，告警就自己消失了。
扩容窗口只剩两小时，照着这个时间表操作
如果降载之后依旧告急,那才是真正需要扩容，两小时窗口内，时间要按分钟算，我见过不少运维同行，把时间浪费在跑top、翻监控大屏上，结果真正动手只剩半小时。
推荐这样分配时间：
- 前15分钟：降载，杀会话，停非核心查询，把数据库从濒死状态拉回来
- 第15到60分钟：做不需要重启的热扩参数，控制台或命令行逐个调
- 第60到90分钟：观察新参数是否生效，连接数是否稳定，慢查询数量是否回落
- 第90到120分钟：留着缓冲，不要再做任何大动作，防止新问题叠加
这期间,值班的人一只手放在回滚预案上，另一只手才能放心调整参数，扩容动作做得越晚，风险越低，因为留给系统磨合的时间越少。
分拣系统数据库告警怎么办？原地热扩别加内存
很多人的第一反应是加内存条,但晚班分拣高峰的数据库，服务器在机房里插拔内存根本不现实，云主机修改规格也要停机，原地热扩，指的是不重启数据库实例，只调整动态参数，让现有进程吃掉更多系统资源。
数据库扩容怎么操作？连接池和缓冲池先动
把数据库想成分拣中心的值班室,连接池是工位，缓冲池是手边的货架，工位不够，加几个位置马上能接更多电话；货架不够，调整大小也快，这两个参数是晚班扩容的首选。
命令路径如下：
- 查看当前连接池上限：
SHOW VARIABLES LIKE 'max_connections'; - 查看当前活跃连接数：
SHOW STATUS LIKE 'Threads_connected'; - 动态抬高连接数：
SET GLOBAL max_connections = 1024; - 查看缓冲池大小：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; - 动态扩大缓冲池：
SET GLOBAL innodb_buffer_pool_size = 1073741824;
注意,缓冲池动态扩大会触发缓存重排，期间CPU会有一个短暂的爬升，别慌，等一两分钟就平稳了，连接数也不是越大越好，连接过多会加剧锁竞争，晚班分拣的高并发短事务场景下，连接数撑到原来的1.5倍通常就已经足够。
大多数云数据库控制台也支持在线修改参数,有些参数改了会提示“需要重启实例”，两小时窗口内，凡是需要重启的参数，一律先跳过，除非你确定重启能在五分钟内完成并且缓冲池预热足够快。
扩容窗口只剩两小时，这些操作绝对禁止
晚班高峰的数据库,最怕的不是扩不动，而是乱动，这几个操作，两小时窗口内碰都不要碰：
- 禁止跑
ALTER TABLE，哪怕只是加一个索引，分拣主表数据量大，加索引要重建表空间，锁表时间可能长达几十分钟，分拣线直接停摆 - 禁止执行
OPTIMIZE TABLE，这是整理表碎片的高危操作，会从头到尾扫描数据文件 - 禁止修改
redo log文件大小，这个操作需要先关库，再删日志文件重建，几乎等于把数据库推倒重来 - 禁止强制重启数据库，MySQL重启后缓冲池是冷的，分拣主查询要重新从磁盘读数据，性能会断崖式下跌，晚班高峰扛不住
合理的做法是,把上面两个动态参数改完，再用SHOW GLOBAL STATUS LIKE 'Threads_connected';这类命令每五分钟盯一次，指标如果开始回落，说明扩容方向对了，剩下交给时间。
数据库扩容要花多少钱？长期方案怎么选
临时扩容只是救火,晚班分拣高峰数据库告急这个问题，如果每周都出现，那就得考虑长期方案，钱花在硬件上，还是花在架构上，效果完全不同。
自建服务器扩容和云数据库弹性伸缩，哪个更靠谱
业内专家指出,不少物流企业的自建机房，扩容的实际周期是按周算的，预算申请、硬件采购、上架调优，每一步都卡流程，两小时窗口就算给你，你也来不及把内存条装上去。
云数据库则不一样,控制台上滑一下规格，几分钟内就能完成升配，更重要的是，云数据库支持定时弹性伸缩，可以设定晚班高峰前自动升配，高峰结束后自动缩回来。
| 方案 | 扩容速度 | 成本特点 | 适合场景 |
|---|---|---|---|
| 自建垂直扩容 | 按天/周计 | 前期硬件投入高，峰值后算力闲置浪费明显 | 业务量全年平稳，无剧烈潮汐 |
| 自建水平拆分 | 按周/月计 | 人力成本高，代码改动大 | 数据量持续高速增长，单表已经跑不动 |
| 云数据库弹性伸缩 | 分钟级 | 按用量付费，波峰吃资源，波谷不花钱 | 晚班分拣这类波峰波谷明显的场景 |
自建服务器扩容,内存条买回来才是刚开始，还要考虑机器电源、散热、磁盘IO，云数据库虽然按量付费单价略高，但晚班高峰只有晚上几个小时，按量付费的综合成本，比自建机器闲置一年的电费和机柜费便宜得多。
数据库扩容大概要多少钱？成本模型拆开看
价格没法给一个固定数字,因为分拣系统的数据量、地域机房位置、网络带宽都会影响成本，但有一点是确定的：长期包年包月的自建机器，和弹性伸缩的按量付费，差的不是单价，而是对闲置资源的浪费。
行业共识认为,分拣类业务数据库的负载峰值，往往集中在晚上6点到10点，其余时间利用率很低，如果按峰值规格常年购买，相当于一个分拣中心为了晚班两小时，养着全天24小时的场地和人员，弹性伸缩方案按实际用量计费，晚班高峰扩到最大，第二天早上缩回最小规格，费用自然降下来。
晚班分拣数据库扩容常见问题解答
晚班分拣高峰数据库扩容窗口只剩两小时，先扩容还是先限流？
如果数据库已经告警超过十分钟,建议先限流，分拣线宁可慢一点，也不要断，接入层可以用Nginx限制单IP并发，或者网关层丢弃超时请求，先把瞬间涌入的订单压住，等到活跃会话数回落到安全区间，再开始做扩容参数调整，顺序不能颠倒。
分拣系统数据库告警，CPU高和IO高分别怎么处理？
CPU高优先看慢查询,SHOW PROCESSLIST里如果大量出现Sorting result或Copy to tmp table，说明是SQL扫描数据量过大，IO高优先看磁盘队列长度，iostat里的util长期超过90%，说明存储层扛不住，先把热数据放进缓存，再考虑把查询切到只读副本，CPU和IO同时告急，优先降载，而不是扩资源。
两小时扩容窗口做不完，数据库还有救吗？
兜底方案是把分拣系统切到半离线模式,订单批量写入本地队列，应用层先不查数据库，数据库只剩一条核心链路，只处理主订单写入，其他查询全部拒绝，历史上不少分拣系统在高峰期就是用这种办法扛过去的，牺牲掉非核心功能，保住主分拣线，等扩容完成后，再把队列里的数据补写进去。