如果单表数据量大，只能考虑分库分表吗

程序员最怕啥？不是需求改八遍，也不是半夜报警电话，而是数据库突然卡成PPT！尤其是当单表数据冲到几千万行，查询慢得像老牛拉车，这时候团队第一反应往往是：“赶紧分库分表！”
但兄弟，分库分表可不是什么温柔小姐姐，它更像是个浑身带刺的仙人掌——你以为抱上就能解决问题，结果可能扎得你嗷嗷叫。今天咱就聊点实在的：数据爆炸时，除了分库分表，咱还有哪些保命招数？

一、分库分表有多坑？试试就知道

（能劝一个是一个）

把分库分表当“万能解药”的兄弟，八成没经历过这些场景：

• 跨库事务？不存在的！ 就像你同时给5个人转账，结果A账户扣了钱，B账户没收到，这时候咋整？分布式事务的坑能让你怀疑人生。
• 自增ID直接废了 以前轻轻松松拿个1、2、3当主键，现在得搞雪花算法、UUID，甚至得专门养个“发号器”服务，代码里全是魔法数字。
• 简单查询变“拼多多” 原本一句SELECT * FROM user WHERE age>18就能搞定，现在得跑遍所有分片，把结果在内存里拼起来，内存直接爆炸。
• 运维小哥哭晕在厕所 监控得盯着10个库，备份策略复杂到要画思维导图，扩容就像给高速行驶的汽车换轮胎——稍有不慎全村吃席。

真实案例：
某电商搞大促，本来分库分表是为了抗住流量，结果库存扣减因为跨库事务超时，30%订单直接失败。CTO当场血压飙升：“这特么还不如不分！”

二、先别急着分！试试这7个土方子

1. 索引优化：给数据库穿双跑鞋

• 别上来就搞分库分表，先看看你的索引是不是像老太太的裹脚布——又臭又长？