最近老李老给我打电话抱怨，他那兑换系统一到周末就卡，会员兑个礼品等半天，客服电话被打爆。我让他查查订单表行数，他截图发过来——一百四十万条。我乐了，这哪是服务器不行，这是单表被你撑爆了。今儿就唠唠兑换系统订单破百万卡顿这事儿，分库分表这套老法子到底咋用，小白也能听明白。

兑换订单卡成狗，锅根本不在服务器

兑换系统卡顿八成是订单表数据量撑爆了单表查询上限，加内存换服务器都是治标，分库分表才是根上的解法。

上礼拜在小区门口大排档，老张端着啤酒跟我诉苦，说他刚换了台32核64G的新服务器，兑换系统还是慢得跟蜗牛似的。我问他订单表多少条，他挠头说一百二十万。我跟他说兄弟你这钱白花了，单表过百万行，MySQL的B+树索引深度往上蹿，随便一个带条件的查询都得扫一片数据，加再多内存也救不了。

老张那套兑换商城跑了三年多，订单表从一开始的几千条涨到现在一百多万，索引建了七八个还是慢。这事儿难吗？其实不尽然。问题不在硬件，在于你这张订单表从根上就没法再撑了。MySQL这种关系型数据库，单表两千万行是个公认的拐点，到了之后查询性能断崖式往下掉，不是你加索引能解决的。

▸ 单表过百万就该琢磨分表了，等到破千万才动手，那叫抢救不叫优化。

分库分表到底是啥玩意儿，小白先搞懂这个

分库分表说白了就是把一张大订单表拆成多张小表，分散到多个数据库实例上，查询压力也跟着分摊，不再压在一台机器上。

这概念听着唬人，其实跟你家里收纳一个道理。你一个衣柜塞五百件衣服，找一件得翻半小时；分到五个衣柜，每个一百件，找起来就快多了。分库分表干的就是这活儿。

具体怎么拆，常见有两条路。一条是垂直拆，按业务把订单表、用户表、商品表分到不同的库，各管各的，互不打架。再就是水平拆，把订单表本身按某个规则切分成多张结构一样的表，比如按用户ID取模分到十张表里。前者治业务耦合，后者治数据量爆炸，兑换订单破百万这种场景，水平分表才是对症的药。

▸ 垂直分治业务乱，水平分治数据多，订单破百万这病得用水平分表治。

中间件这块，老李那套用的是ShardingSphere，社区活跃文档全，小白上手不费劲。早些年MyCat也火过一阵，现在用的人少了，新项目不太建议碰。这俩工具的活儿就是把分表的脏活兜起来，你写SQL它帮你路由到具体的表，你不用每个查询都手动判断走哪张。

实操落地，订单表怎么切才不踩雷

兑换订单表水平分表，按用户ID取模是最稳的路子，能保证同一用户的订单落在一起，查询不跨表；按时间分表适合归档但不适合实时查询，别选错。

这块是重头戏，我多唠两句。分表键选啥直接决定你后面好不好过。老张一开始想按订单时间分表，一个月一张，听着清爽。结果会员来查"我去年兑换过啥"，跨了十二张表查一遍，慢得他想撞墙。

为啥按用户ID分更靠谱？你想啊，兑换系统的查询九成都是"某用户的订单列表"，把同一用户的订单都路由到同一张分表里，查的时候只扫一张表就完事，性能立马就上来了。订单号这块也得改造，得带分表信息进去，不然你拿到一个订单号都不知道去哪张表查，这就叫分片键冗余进主键。

对了，跨库查询和分布式事务这俩坑你得提前知道。分完表之后，分页、统计、报表这些原本一句SQL搞定的事儿，现在得跨多张表汇总，要么用中间件帮你聚合，要么自己写代码兜。分布式事务更麻烦，兑换扣积分加订单这种操作跨了库，本地事务管不了，得上Seata或者改造成最终一致。老张当初没考虑这个，上线第二周积分扣了订单没生成，会员投诉一波接一波。

▸ 分表键选用户ID，订单号带分片信息，这俩原则照着做少走半年弯路。

分完表就万事大吉？这几个坑照样埋人

分库分表不是银弹，历史数据迁移、跨表分页、全局唯一订单号这三个坑不提前规划，上线即翻车。

老李跟我说他分表那天通宵到凌晨四点，第二天起来发现历史订单没迁过去，会员查不到老订单炸了锅。这事儿我见多了。历史数据迁移得提前写脚本，按分表规则把老数据重新打散到新表里，迁完还得校验条数对不对得上，少一条都是事故。

跨表分页这个坑更阴。前端列表第二页、第三页这种翻页操作，分表之后没你想象的那么简单。每张表都得查前N条，再在内存里合并排序取指定页，数据量一大内存扛不住。常见解法是限制最大翻页深度，或者用游标分页代替传统offset，别让用户翻到第一百页。

全局订单号这事儿也得拎出来说。分表后自增主键肯定不行了，多张表会撞号。业内用的多的是雪花算法，或者你直接上号段模式，提前从库里取一段ID缓存到本地用。这块写代码的时候别偷懒，订单号重复了哭都来不及。

▸ 数据迁移、跨表分页、全局ID，分表落地前先把这三个坑填平。

小老板真不一定非要上分库分表

订单表百万级卡顿，先试试读写分离、加索引、历史订单归档这几招便宜的，确实顶不住再上分库分表，别为了优化而优化。

这话我得说在前头。分库分表是个重活儿，运维成本、改造成本都不低，团队没几个懂行的人，硬上反而把自己绕进去。我见过不少小老板听说分库分表高大上，订单才三十万条就张罗着拆，拆完发现还不如不拆。

便宜的招儿先试。读写分离搞个从库专门扛查询，主库写订单，成本不高见效快。索引再review一遍，是不是有该建没建的、是不是建了没用上的。还有一招特好用——历史订单归档，把半年前甚至一年前的订单挪到归档表里，主表只留热数据，立竿见影。老李后来就这么干的，半年以上订单搬走，主表瞬间回到四十万条，响应时间直接砍掉一大半。

啥时候才真该上分库分表？你订单表奔着两千万去了，归档也归档不动了，读写分离也撑不住了，那时候再动手不迟。技术选型这事儿，够用就行，别折腾。

▸ 归档和读写分离先顶着，真到了两千万再分表，别跟风瞎拆。

能简单解决的事别上重武器，分库分表这把刀，留给真撑不住的那天再用。