昨天凌晨三点，客服群里炸了锅。说是用户下单支付成功了，后台却查不到订单，导致骑手没接单，用户饿着肚子等了一小时才把餐送过去。老板当时脸都绿了，拍着桌子问我到底怎么回事。

这事儿其实挺常见。很多做本地生活的团队，一上来就觉得自己技术牛，拿着最新的NoSQL方案往里硬塞。觉得什么Redis、MongoDB才叫高级，把订单、用户、菜品这些核心业务数据全混在一起存。结果呢？流量稍微大一点，比如中午高峰期，接口响应时间直接从50毫秒飙升到2秒，用户点个“支付”都要等半天，体验感直接拉垮。

说实话，订餐网站的数据库建设真不是越花哨越好。你得先搞清楚你的数据长什么样。

我见过一个刚起步的团队，他们把“菜品评价”和“核心订单流水”放在同一个分库里。结果呢，高峰期大家疯狂看差评和好评，把数据库的连接池全占满了，新订单根本插不进去。这就是典型的读写干扰。后来我们花了整整一周时间做分库分表，把高频读的评价数据拆出去，用专门的缓存层去扛，核心订单库只专心处理交易。这一拆，QPS直接翻了三倍，稳定性才提上来。

还有个大坑，就是“软删除”和“历史数据归档”。

有个朋友的项目，做了两年没清理过一次老数据。数据库里堆了几千万条“已取消”、“已作废”的订单。每次后台查询都要扫描几亿行的数据，哪怕加了索引，慢查询日志还是天天报警。后来我们搞了个定时任务，把超过180天的冷数据转移到归档库，只保留最近半年热数据在主库。主库的体积直接缩小了60%，查询速度那是肉眼可见的快。

说到这里，很多人会问，到底用什么架构最合适？

我的经验是，中小型项目，MySQL主从复制+读写分离就足够了，千万别为了用而用新技术。如果你的日订单量过了万单级别，再考虑引入分库分表中间件，比如ShardingSphere。对于实时性要求极高的库存扣减，可以考虑在Redis里做预扣减，再异步同步到MySQL，这样既能扛住并发，又能保证最终一致性。

订餐网站的数据库建设，本质上是在“一致性”和“可用性”之间找平衡。你可以容忍偶尔一次库存超卖然后人工退款，但你不能容忍用户钱付了单没了。前者是业务成本，后者是信任成本。信任崩塌了，这网站就废了。

另外，别忽视日志和数据备份。很多小团队觉得备份太麻烦，或者备份恢复太慢就不测。直到有一天磁盘坏了，数据丢了一半，才发现所谓的“自动备份”从来没生效过。一定要定期做恢复演练，不然那备份就是个摆设。

最后给点实在的建议。如果你的系统现在还在裸奔，没有监控，没有预警，赶紧停下来补这个课。别等出了大事故再补救，那代价太大了。

我手头有一套针对高频交易场景的数据库调优清单，涵盖了从索引优化到连接池配置的几个核心坑位。如果你正在做类似的系统，或者对架构设计有疑问，欢迎来聊聊具体的业务场景。我们可以一起拆解下你的数据模型，看看哪里还有隐患。毕竟，踩坑多了，路才能走得平实点。