你正在白板上画着数据库架构，信心满满地抛出“然后我们给数据库做分片（Sharding）。”面试官笑了，追问一句：“为什么？为什么不能就用数据库分区（Partitioning）？”你愣住了。

这就是缺乏生产级心智模型的下场。教科书定义说“分区是本地操作，分片是分布式操作”，但当系统真正出问题时，这些干净的定义救不了你。今天我们抛开小抄，看看两者真正的运维差异、隐藏瓶颈，以及怎么选。

打开网易新闻 查看精彩图片

在写任何DDL之前，先记住一条黄金法则：所有分片都是分区，但不是所有分区都是分片。分区是把数据切成小块，目标是为了可管理性或性能，比如让查询跑得更快。分区不一定意味着分布式系统。分片是一种特殊类型的分区，这些分区分布在不同的机器上，这才是真正的水平扩展。分片的核心目标就两个——更高的吞吐量、更大的存储容量。

我们先看第一个场景。假设你搭了个电商平台，订单表膨胀到了5亿行，延迟图惨不忍睹，查最近订单的请求慢得爬一样。最佳做法是按日期或月份分区。查询变快，旧分区可以归档，维护简单，还没有额外的机器成本。工程收益是：分区剪裁，用户查最近订单时，查询计划器瞬间忽略掉95%的表，只在特定月份的分区文件里搜；还有零成本数据留存，数据变旧后，不用跑一次锁死CPU的大规模Delete，直接删除或归档整个历史分区文件就行。看到没？分区解决的是查询效率，不是机器容量。

现在看第二个场景。你的平台爆火，有了5000万活跃用户，主数据库机器写吞吐撑不住了。CPU打满，磁盘I/O饱和，连接池耗尽。这时候光靠分区不够了，瓶颈不再是查询优化，而是单机资源。一旦CPU、内存、存储或者写吞吐成为数据库机器的瓶颈，你就得考虑分片。你可以把用户ID 1到1000万映射到分片A，1000万到2000万映射到分片B，以此类推。这样写请求就分散到不同的分片上，写吞吐自然就上去了。

记住，分区能救字段漫无目的的查询，分片才能解资源到头了的困局。下次面试再被追问，别复述定义，把这两个场景甩出来，你看到的就不是问题，而是心照不宣的微笑。