在数据库的世界里，写个查询（SELECT）实际上挺好办，但真正搞定分库分表（Sharding），就像是在一个庞大的乐高世界里，把一块块砖头拼在一起，还得确保它们能自动滑到位，互不干扰。
那会儿我诟病过分库分表，认定它像给数据库搞了个拆东墙补西墙的“易碎操作”，时常出于配置不当把业务给搞崩，就连出现数据对不上的尴尬场面。 但后来发现，分库分表不是让数据“搬家”那么好办，它更像是一种架构上的权衡。想象一下，你有一张 1000 万行用户表，要是全塞进一块硬盘，哪怕硬盘有 100TB，数据密度你也得扔了。
这时候，你有了两个选择：要么数据量小，换个更大点的硬盘；要么数据量大，把硬盘切成几块，分别存几块数据。分库分表就是后者，它把数据切分成多块，切分好了就分几个小表，再让不同的机器分别存这些小表。 这就好比把一锅饭分给六个人吃。
本来这锅饭得放在一个人面前，六个人就得轮流去端盘子。分库分表就是这盘饭，每个人（每个分库）手里拿着几把盘子（分表），只要大家端着盘子进食，大家手里的饭量一般是一样的。 那分库分表到底是如何“分”的？这里面有个挺核心的逻辑，叫 KeySet。大量人认定这是专名词，实际上说白了就是用来拍板数据归哪儿的规则。
这规则得写得清清楚楚，不然数据往哪放都不晓得。举个具体的例子，我们给一个电商订单表做分库分表，选了天作为分片键（Sharding Key）。
那天是日历年，比如今天是 2024 年 5 月 20 日，那么所有的订单就按这个日期分成几块。
这时候，订单表被切成了 12 个分表（12 天），每个分表里大约 83 万单。 顺着这个规则走，你发现最近几天（比如 2024 年 5 月 10 日 -5 月 19 日）的重卖订单特别多，那这几天的数据在 12 个分表里就显得特别宽，占的空间大；而一年前要么挺久那会儿的订单，数据自然就少，占的空间小。
这种不均匀分布实际上是分片设计的“特征”，就像人发胖了肚子会鼓，瘦了肚子会瘪一样，数据量大小直接拍板了分表在物理空间里的“胖瘦”。 要是你的 KeySet 没选好，那后果挺严重。
比如我选错了分片键，害得某一年所有的订单都扔进了一个分表，那这个分表就瞬间撑爆了，其他分表的数据可能就一辈子无法访问了，业务直接瘫痪。
故此，选 KeySet 就像画地图，你务必知道哪个方向是“分片键”所在，哪条路是“数据流向”。 那分库分表分完赶明儿，数据到底去哪了？往往会有个误区，认定数据是“分片”了，那自然分几块了。
实际上不然，分表只是物理上的切割，数据本身还是那些行。分库分表的核心逻辑是：数据不留在分片里，而是被“环游”一遍。 分库是物理隔离，分表是逻辑分布。数据流程是这样的：客户端发起请求，数据先被分发（Shard）到某个具体的分表（比如 12 个分表中的一个），这个分表再被分库（比如取个库 ID，如 100 号库），最终拿到具体的服务器机器。客户端发出的数据，一路向下钻，直到数据库的底层。别看数据在物理层面上已经被切分到不同的服务器，但在逻辑上，它看起来像是还在原来的分库里。 这就有点像把房间里的书分到书架上。分库是物理上把书分进不同的房间，分表是物理上把书分进不同的书架。但要是你在书架上找书，你依然是按照“书的分类”去找，而不是跑到“隔壁房间”要么“隔壁书架”去找。
这就是分库分表真正的价值：它强调逻辑上的地址显式明确，物理上的存是分散的，但业务逻辑上的“家”还是那个家。 再说说如何分表，这实际上是个关于“如何描述数据”的过程。分表往往用 TO 字段（Table）来标记，TO 字段的值代表了分表在物理空间里的位置。但这里的 TO 不是存大文件的地方，它是用来告诉数据库：“别往这个位置存数据了，别往那个位置存数据了，把这个位置让给别的组”。 要是在数据库配置里，TO 字段的值配置毛病了，数据库中就会乱套。
这时候，数据库的元数据就分不清哪个表对应哪个分表了，害得分表数据无法被对路由。
这时候，数据库可能会报错，要么把数据往毛病的地方塞。
这就是为啥大量人认定分表配置一旦错了，就没法改。 自然，分库分表不是万能的。它益处是能削峰填谷，闲的时候数据少，忙的时候数据多，避免单点过载；能解决海量数据难题，让数据库能处理更多行。弊端就是数据一致性略微复杂一点，出于不同地方存的数据，可能在某些时序上有个细小的ズボンズ（Zombie，即死数据风险）要么延迟，处理不好就好办出现数据不一致。 在实际搭建过程中，大家一般会在初始化分库时，把某个库的 ID 给存到某个特定的列里，比如一个 UUID 要么一个整数。
这个 ID 就是分表的键，它拍板了数据被路由到哪个分表，和哪个分库。 总结一下，分库分表就是把大量数据切割成小块，再让不同的机器分别存这些小块，与此同时保持业务逻辑上的地址一致。分库是物理隔离，分表是逻辑分布，数据流程是环游。别看它带来了物理上的分散，但逻辑上的“家”还是那个家，逻辑地址是显式明确的。
只要在初始化分库时把某个库的 ID 给存到某个特定的列里，这个 ID 就是分表的键，它拍板了数据被路由到哪个分表，和哪个分库。 分库分表是个技术动作，不是业务动作。业务不需求关心分库分表，业务只需求关心数据如何取。它是个支撑技术的架构手段，就像盖楼时的钢筋水泥，别看看不见，但拍板了楼能不能盖得高。
