老张在市中心开了家连锁奶茶店，最近生意火爆，分店从3家扩到10家。可问题也来了——收银系统卡顿、订单数据延迟、会员积分不同步。他原以为是Wi-Fi信号差，换了路由器也没用。其实，真正的瓶颈藏在后台：数据库扛不住流量了。
扩容不是换个大硬盘那么简单
很多商家一说网络慢，第一反应是升级带宽或换服务器。但对多门店商铺来说，真正的压力来自并发访问和数据同步。比如午高峰时段，10家店同时下单、查库存、更新会员信息，数据库连接数瞬间飙到上千。老旧的单机MySQL根本撑不住，响应延迟直接导致前台卡死。
这时候，光加内存、换SSD只是治标。得从架构上调整，让数据库“能伸能缩”。
读写分离：把进账和记账分开干
就像小卖部老板自己收钱，媳妇记账，分工才不乱。数据库也能这么拆——主库负责写入（如下单、退款），从库负责读取（如查余额、看订单）。通过MySQL的主从复制，写操作先落主库，再异步同步到从库。
CHANGE MASTER TO \
MASTER_HOST='master-server-ip', \
MASTER_USER='repl', \
MASTER_PASSWORD='slave-password', \
MASTER_LOG_FILE='mysql-bin.000001', \
MASTER_LOG_POS= 107;这样，前台查询全走从库，主库轻装上阵处理交易，压力立马减轻一半。
分库分表：别把所有鸡蛋放一个篮子
当单表数据超过百万行，查询就开始变慢。比如会员表里塞了几万条记录，按手机号查用户就得全表扫描。解决办法是分表：按门店ID或注册时间拆成多个物理表。
更彻底的是分库。比如每三家店用一个独立数据库实例，数据物理隔离。配合中间件如ShardingSphere，应用层无感切换。
<!-- 配置分片规则 -->
<rule>
<table name="orders" actual-data-nodes="ds$->{0..3}.orders_$->{0..3}"
database-strategy-ref="db-by-shop"
table-strategy-ref="tb-by-month" />
</rule>缓存先行：热门商品别总问数据库
夏天爆款杨枝甘露一天卖500杯，每次下单都去查一次库存？没必要。用Redis把商品信息、库存余量缓存起来，前端先查缓存，命中就直接返回。只有减库存这种关键操作才落到数据库。
设置个10分钟过期，既能防雪崩，又保证数据不过时。实测下来，90%的读请求被拦在数据库之外。
监控不能少：早发现，少背锅
上了扩容方案，不代表高枕无忧。建议加个Prometheus+Grafana监控组合，盯住连接数、慢查询、CPU使用率。某次系统卡顿，老张靠监控图发现是某个店员误刷了上千条测试订单，及时止损。
商铺网络扩容，表面看是网络问题，根子常在数据层。提前布局好数据库架构，才能让生意越做越大，系统越跑越稳。